Waarom SaaS-escrow?
28 november 2023

Origineel is van 1 december 2014

In deze uitgebreide blog gaan we in op de vraag ‘Waarom SaaS-escrow?’. Eerst kijken we naar het verschil tussen SaaS en on-premise oplossingen. Dan bespreken we de verantwoordelijkheden van de SaaS-eindgebruiker. Vervolgens leggen we kort uit hoe broncode-escrow werkt en bespreken we wat je voor SaaS-oplossingen nog meer moet regelen op escrow gebied.

Verschil tussen SaaS en on-premise oplossingen

Net als dat bij on-premise oplossingen het geval is, krijgt de eindgebruiker van SaaS tegen betaling een gebruiksrecht op de software. Verschil met ‘traditionele’ licenties is echter dat de softwaregebruiker ook de toestemming moet hebben om gebruik te maken van de hardware en infrastructuur op afstand, waarmee de toegang tot de software feitelijk aan hem geleverd wordt. De SaaS-gebruiker krijgt geen objectcode-exemplaar. Maar met de inloggegevens die zijn leverancier hem heeft verstrekt, krijgt hij online toegang tot de software en de daarmee verwerkte gegevens. Het beschikbaar houden van de toegang gebeurt onder de verantwoordelijkheid van de leverancier, die daarbij vaak derde partijen inschakelt.

Een veelvoorkomend voorbeeld: de leverancier ontwikkelt en onderhoudt de software, maar een hostingprovider verzorgt de beschikbaarheid van de software en data. De gebruiker heeft niet in beeld door wie en hoe het totale SaaS-systeem functionerend wordt gehouden. Meerdere partijen kunnen hierbij betrokken zijn. Het wegvallen van één van die partijen kan het gebruik van de software en de toegang tot de data al frustreren.

De SaaS-gebruiker: wel verantwoordelijk, maar geen beschikkingsmacht

De SaaS-eindgebruiker is de primair verantwoordelijke voor de continuïteit van zijn eigen bedrijfsvoering. Wanneer die continuïteit mede wordt bepaald door de continuïteit van het onderhoud en gebruik van de SaaS-applicatie en de daarmee verwerkte gegevens, betekent dit dat hij dat onderhoud en gebruik veilig moet stellen. Maar de stappen die hij hiervoor moet zetten, kan hij meestal niet alleen zetten. Dat is bij on-premise software het geval, maar des te meer bij SaaS. En dan hebben we het nog niet eens gehad over het feit dat bij een faillissement na een doorstart, de nieuwe eigenaar van de IE-rechten de licentie misschien niet voortzet. Daar komt bij dat de data bij SaaS ook op een andere locatie is opgeslagen dan bij de eindgebruiker, waardoor hij er in het geval van discontinuïteit van de leverancier niet meer bij kan.

Dit alles klinkt negatief, maar uiteraard moet niet uit het oog worden verloren dat het buitenshuis laten beheren van IT de eindgebruiker grote (kosten)voordelen kan bieden. SaaS is dan ook een succesvol businessmodel, al betekent dit dus niet dat de SaaS-eindgebruiker minder (eind)verantwoordelijkheid heeft voor de continuïteit van zijn software. Bovendien moet hij meer doen om die verantwoordelijkheid goed in te vullen.

Broncode-escrow: oplossing voor continuïteitsrisico’s SaaS-eindgebruiker?

Het zorgen voor continuïteit van bedrijfskritische software is voor een softwaregebruiker zonder medewerking van zijn leverancier niet eenvoudig. Een mogelijke oplossing is dat de leverancier een broncode-escrowregeling aangaat met een escrow-agent. Dan krijgt de softwaregebruiker in het geval van een calamiteit toegang tot de broncode van de software en de daarbij horende technische documentatie. Hierdoor wordt de gebruiker dus minder afhankelijk van de leverancier: softwarecontinuïteit wordt als het ware losgekoppeld van het voortbestaan van de leverancier.

Broncode-escrow alleen is voldoende (mits technisch en juridisch goed geregeld) voor de gebruiker van on-premise software dat door hemzelf draaiend wordt gehouden. Met de toegang tot de broncode kan hij op de lange termijn voorzien in het onderhoud en de doorontwikkeling van de software. Met de veiligstelling van een (curator-proof) gebruiksrecht op de software is hij ook op de korte termijn verzekerd van het onafgebroken gebruik van de software: hij heeft immers reeds een werkend objectcode-exemplaar ervan in huis. Ook de gegevens die met de software worden verwerkt, zijn intern en op eigen gegevensdragers vastgelegd.

Bij SaaS is aanvulling op broncode-escrow nodig

Voor de eindgebruiker van SaaS is broncode-escrow daarentegen onvoldoende. Dat komt met name omdat het onafgebroken gebruik van de software niet meer kan worden bewerkstelligd met een stevig gebruiksrecht en een werkend exemplaar van de objectcode. De eindgebruiker kan immers niet terugvallen op de hardware (infrastructuur): daar is de inzet van de leverancier voor nodig.

De leverancier is verantwoordelijk voor het dagelijkse beheer van de door hem aangeboden SaaS-oplossing. Verder is hij degene die de voor de levering van de software ingeschakelde derden betaalt voor hun diensten. Deze derden hebben geen directe contractuele afspraken en verplichtingen tegenover de SaaS-eindgebruiker, waardoor zij hun dienstverlening zouden kunnen staken op het moment dat de leverancier hen niet meer betaalt. Leveranciersonafhankelijke softwarecontinuïteit is bij SaaS daarom lastiger te bewerkstelligen dan bij on-premise software.

Technische en juridische beschikkingsmacht

Net zoals bij broncode-escrow is verzorgen van de continuïteit van SaaS-oplossingen een multidisciplinaire aangelegenheid. De gebruiker moet niet alleen over de technische middelen (broncode, documentatie, data etc.) beschikken die voor het verzorgen van zijn continuïteit noodzakelijk zijn (de technische beschikkingsmacht). Hij moet ook het recht hebben om die zaken te gebruiken (de juridische beschikkingsmacht).

Het is de vraag of de gebruiksrechten die hij via de SaaS-overeenkomst heeft gekregen, voldoende zijn. Allereerst zit het gebruiksrecht alleen op een draaiend exemplaar van de objectcode van de applicatie, die niet op de apparatuur van de gebruiker is geïnstalleerd. De gebruiker kan met enkel de SaaS-overeenkomst in de hand geen aanspraak maken op de broncode. Hetzelfde kan ook gezegd worden over de data: zonder specifieke afspraken is de SaaS-gebruiker niet zonder meer eigenaar van zijn eigen (en andere noodzakelijke) data.

Continuïteit SaaS bij faillissement leverancier?

Die vraag wordt extra relevant op het moment dat de leverancier wegvalt, bijvoorbeeld omdat hij in staat van faillissement is verklaard. De curator kan de intellectuele eigendomsrechten namelijk verkopen aan een andere partij. Als SaaS-eindgebruiker heb je niet in de hand wat deze andere partij gaat doen. Gaat hij de licentie überhaupt continueren, gaat hij veel aanpassingen maken in de applicatie of een hoger bedrag vragen? De nieuwe partij kan dus de continuïteit van een SaaS-oplossing en de beschikbaarheid van de daarmee verwerkte data gemakkelijk frustreren.

Dit is een onvoorspelbare factor waarmee in een continuïteitsregeling voor SaaS rekening gehouden moet worden. Belangrijk hierbij is dat de SaaS-escrow-oplossing ook door derden gerespecteerd moet worden en dat ook de curator geen roet in het eten moet kunnen gooien.

Verzorgen continuïteit SaaS: algemene aandachtspunten

Bij een SaaS-oplossing zijn er een aantal componenten van het SaaS-informatiesysteem door de eindgebruiker uit handen gegeven. Het gaat in de hoofdzaak om de software, de hardware, de data en het operationele beheer. In elke continuïteitsregeling moet dus in ieder geval aandacht aan deze specifieke zaken worden besteed. Daarnaast spelen de volgende algemene aandachtspunten een rol  bij het verzorgen van de continuïteit van SaaS:

Continuïteit voor de korte en lange termijn: Allereerst moet rekening worden gehouden met het feit dat de regeling zowel op korte als op lange termijn continuïteit dient te bieden. Bij het wegvallen van de SaaS-leverancier betekent dat op korte termijn dat het onafgebroken gebruik van de applicatie en de onafgebroken beschikbaarheid van de data worden veiliggesteld. Op de lange termijn betekent dit onder andere dat het onderhoud en de doorontwikkeling van de software voortgezet moet kunnen worden. De gebruiker moet dus de rechten krijgen waarmee hij de SaaS-oplossing kan laten aanpassen en laten beheren. Een overstap naar nieuwe software moet voorkomen worden. Het overzetten naar de eigen hardware of naar een andere derde partij is soms onvermijdelijk. Niet elke leverancier gebruikt immers een hosting partij, sommigen doen het ook zelf.

Een continuïteitsregeling is maatwerk: Een tweede aandachtspunt is dat het opzetten van een continuïteitsregeling maatwerk betreft. Alle SaaS-informatiesystemen en de daarachter liggende ketenstructuren verschillen van geval tot geval. Dit betekent dat het pas duidelijk is welke continuïteitsmaatregelen moet worden genomen, op het moment deze zaken in kaart zijn gebracht. Bovendien is dit een multidisciplinaire aangelegenheid. Een gedegen technisch en juridisch vooronderzoek is dus noodzakelijk.

Afwegen van de kosten ten opzichte van het risico: Bij het opzetten van de regeling spelen verder de kosten van continuïteit een rol. Er mag geen afbreuk worden gedaan aan de economische voordelen die voor de eindgebruiker misschien juist de beweegreden zijn geweest om op SaaS over te stappen. Dat betekent dat er altijd een afweging is tussen de kosten van een continuïteitsmaatregel enerzijds en de omvang van het af te dekken risico anderzijds.

In het algemeen kun je stellen dat het verloop van een calamiteit bij de leverancier en de afwikkeling daarvan van te voren moeilijk te voorspellen is. Bijvoorbeeld bij een faillissement kan dit het einde van de leverancier betekenen, maar een curator kan proberen om een doorstart te organiseren. Een curator is niet de enige onzekere factor. Ook mag je er niet vanzelfsprekend vanuit gaan dat de noodzakelijke partijen die onderdeel zijn van de SaaS-keten hun medewerking verlenen. Een escrow-dienstverlener dient dus in het belang van de eindgebruiker zoveel mogelijk rekening te houden met alle mogelijke scenario’s en hier zoveel mogelijk op voor te sorteren.

Verzorgen continuïteit SaaS: software en hardware – korte termijn

Bij het verzorgen van de continuïteit van een SaaS-informatiesysteem moet ten eerste de software worden veiliggesteld. Op de korte termijn is nodig dat de software onafgebroken kan worden blijven gebruikt wanneer de SaaS-leverancier wegvalt. De gebruiker moet de rechten hebben om de applicatie in het geval van een calamiteit bij zijn leverancier te blijven gebruiken: de inhoud van zijn softwarelicentie moet in stand blijven.

Daarnaast moet bij een calamiteit de feitelijke beschikbaarheid van de software en dus de beschikbaarheid van de hardware waarop de software draait, worden verzorgd. De partijen die binnen een SaaS-keten hiervoor verantwoordelijk zijn, moeten daartoe technisch én juridisch in staat zijn. Bovendien moeten zij zich tegenover de gebruiker met zekerheid committeren dat zijn hun dienstverlening continueren, maar deze partijen moeten er ook op kunnen vertrouwen dat zij voor hun dienstverlening betaald blijven worden.

Verzorgen continuïteit SaaS: software en hardware  – lange termijn

Voor continuïteit van de software op de lange termijn dient gebruik te worden gemaakt van solide broncode-escrow. Uitgangspunt is dat alle broncode, technische documentatie, beheersinformatie, hulpsoftware en de overige zaken die noodzakelijk zijn voor het kunnen beheren, reconstrueren en onderhouden van de SaaS-omgeving, toegankelijk moeten zijn bij de escrow-dienstverlener. Deze verzameling van gegevens moet werkzaam en actueel zijn, waarbij bovendien de specifieke kenmerken van SaaS een belangrijke rol spelen.

Zo moet rekening worden gehouden met het feit dat veel SaaS-oplossingen zeer frequent worden geüpdatet, en de broncode ervan dus snel veroudert. Een mogelijke oplossing voor dit probleem kan een mirror-omgeving zijn of regelmatig online deponeren. Zo kan er met behulp van een koppeling aan het versiemanagementsysteem van de leverancier ervoor gezorgd worden dat de escrow-dienstverlener bij totstandkoming van een nieuwe versie van de broncode daarover meteen de beschikking krijgt.

Verzorgen continuïteit SaaS: data en operationeel beheer

Daarnaast dient de escrow-dienstverlener bij het opzetten van de continuïteitsregeling vast te stellen welke organisatorische maatregelen moeten worden genomen: welke partijen moeten wat doen in het geval van een calamiteit bij de leverancier? Moeten werknemers van de weggevallen leverancier betrokken worden bij de voortzetting van het beheer van het informatiesysteem? De afspraken die worden gemaakt, zullen in een contract moeten worden gegoten, zodat de verplichtingen afdwingbaar zijn. De escrow-dienstverlener zorgt ervoor dat de rol van de weggevallen SaaS-leverancier wordt uitgevoerd en dat op operationeel niveau het roer overgenomen kan worden. De escrow-dienstverlener heeft ten slotte de functie van coördinator: hij verzorgt de aansturing van de ketendienstverleners die de SaaS-applicatie draaiend moeten houden.

Wat kunnen wij voor je doen

Wil je weten wat wij voor jouw organisatie kunnen betekenen op het gebied van SaaS-escrow? Neem dan contact met ons op voor een vrijblijvend kennismakingsgesprek. Een berichtje achterlaten via ons contactformulier kan natuurlijk ook.          

Tags

Neem contact op

Meer informatie of een afspraak maken? Bel 050-5344574 of laat hier een bericht achter via ons contactformulier.

Ook interessant om te lezen