Knowhow

U heeft het allemaal geregeld: de continuïteit van de software, domeinnamen, data, hosting en de servers. Dan blijft er nog één onderwerp cruciaal: kennis over de werking van de clouddienst. Om een clouddienst veilig in de lucht te houden is expertise nodig. Komt er bijvoorbeeld een kritieke beveiligingsupdate uit, dan moet deze geïnstalleerd worden. Is er een technisch probleem, dan moet iemand dat probleem kunnen verhelpen. Zonder knowhow over de werking van de clouddienst kan de rest nog zo goed geregeld zijn, maar zal de continuïteitsoplossing waarschijnlijk maar van korte duur zijn.

Om te zorgen dat ook ná een faillissement essentiele updates doorgevoerd kunnen worden, of andere noodzakelijke technische werkzaamheden kunnen worden verricht, werkt de Stichting Continuïteit Internetdiensten samen met deskundige technische partners. Wanneer een clouddienstverlener zich aansluit bij de Stichting Continuïteit Internetdiensten, wordt vooraf geïnventariseerd hoe de techniek achter de clouddienst in elkaar zit. Hoe ziet de documentatie eruit? Zijn de inlogcodes voor de beheeromgeving en andere belangrijke accounts voorhanden? Is de kwaliteit van de broncode van de software op orde?

Soms zijn er naar aanleiding van deze inventarisatie aanpassingen nodig. Daarmee maakt de clouddienstverlener ook direct een professionaliseringsslag. Pas als de techniek op orde is en de technische partner écht in staat is om het beheer van de clouddienst een tijdje over te nemen, wordt de clouddienstverlener op de regeling van de Stichting Conntinuïteit Internetdiensten aangesloten.

Soms kan het wenselijk zijn om ook afspraken te maken met een of enkele essentiële personeelsleden. Wel moet er gewaakt worden dat niet de gehele arbeidsovereenkomst wordt overgenomen. Dit zou de regeling namelijk onnodig duur maken. Er moet een overeenkomst van opdracht gesloten worden die enkel actief wordt indien de continuïteit bedreigd wordt. Natuurlijk moet de werknemer of ZZP’er daar wel voor open staan, slavenarbeid is immers afgeschaft.

Knowhow

U heeft het allemaal geregeld: de continuïteit van de software, domeinnamen, data, hosting en de servers. Dan blijft er nog één onderwerp cruciaal: kennis over de werking van de clouddienst. Om een clouddienst veilig in de lucht te houden is expertise nodig. Komt er bijvoorbeeld een kritieke beveiligingsupdate uit, dan moet deze geïnstalleerd worden. Is er een technisch probleem, dan moet iemand dat probleem kunnen verhelpen. Zonder knowhow over de werking van de clouddienst kan de rest nog zo goed geregeld zijn, maar zal de continuïteitsoplossing waarschijnlijk maar van korte duur zijn.

Soms zijn er naar aanleiding van deze inventarisatie aanpassingen nodig. Daarmee maakt de clouddienstverlener ook direct een professionaliseringsslag. Pas als de techniek op orde is en de technische partner écht in staat is om het beheer van de clouddienst een tijdje over te nemen, wordt de clouddienstverlener op de Stichting Conntinuïteit Internetdiensten aangesloten.

Data en hosting

Indien u gebruikmaakt van een clouddienst, dan zult u vaak ook uw data in de cloud bewaren. Met andere woorden, u voert uw data in en deze wordt niet op uw eigen server opgeslagen, maar op een server van de clouddienstverlener. De server kan in eigendom zijn van de dienstverlener of van een derde partij (de hostingprovider). Om de keten nog langer te maken: de server staat weer in een rack en dit rack staat in een datacenter. Dat datacenter is mogelijk weer van een andere partij.

Er zijn verschillende mogelijkheden om de continuïteit van (de toegang tot) uw data én de applicatie zeker te stellen. Welke optie het beste is, is afhankelijk van wat de dienstverlener wil, wie de hosting levert, waar het eigendom (van de server) ligt en hoever uw budget reikt. Het doel blijft ervoor te zorgen dat uw data en eventueel ook de applicatie intact en toegankelijk blijft, zodat er voldoende tijd is voor migratie van de data of een overname van de applicatie door een andere clouddienstverlener.

Indien de SaaS-dienstverlener de data door een derde laat hosten, dan zal de Stichting Continuïteit Internetdiensten (direct of indirect) afspraken moeten maken met de ingehuurde hoster. Op het moment dat de continuïteit bedreigd wordt, moet deze overeenkomst ervoor zorgen dat de hoster zijn taak blijft uitvoeren en niet de stekker eruit trekt. Juridisch gezien zal er vaak sprake zijn van een overeenkomst die tot leven komt onder de opschortende voorwaarde dat de continuïteit bedreigd wordt.

Het is echter niet handig om zomaar bestaande contracten over te nemen. Hierdoor kunnen de kosten flink stijgen. Er dient gekeken te worden naar wat nodig is. Er moet een periode van continuïteit worden afgesproken waarin de Stichting zorgt dat de rekening betaald wordt en dus de hoster blijft doorleveren.

Het is ook mogelijk dat de dienstverlener kiest voor colocatie. Dat betekent dat de clouddienstverlener de servers in eigendom heeft, maar deze bij een ander in het datacenter staan. Op het moment dat de eigenaar de rekeningen van het datacenter niet meer betaald, is er een mogelijkheid dat de stekker eruit gaat. In het ergste geval wordt de server door de curator verkocht. In een iets minder ernstig geval, is het de datacenter-houder die de stekker eruit trekt. Beide gevallen dienen voorkomen te worden.

Bij een eigen server (van de clouddienstverlener) is het een goed plan om met een sale-and-leaseback-constructie te werken. Houd echter wel mogelijke verpandingen van de servers aan derden in uw achterhoofd. In deze constructie worden de servers verkocht aan een ander dan de dienstverlener, die de servers vervolgens weer aan de dienstverlener verhuurt. Deze ander kan de klant of een aparte economische entiteit zijn. De Stichting Continuïteit Internetdiensten sluit een overeenkomst met de nieuwe eigenaar waarin het gebruik van de servers voor de duur van de continuïteit die geboden moet worden om overname van de dienst of migratie mogelijk te maken geregeld wordt.

Indien uw budget het toelaat en indien het noodzakelijk is voor uw bedrijfsvoering, kunt u er voor kiezen om een mirror van uw data bij een andere hoster te draaien. Óf zelfs een hotstandby; daarmee wordt niet alleen de data dubbel opgeslagen maar ook de applicatie (volledig up-to-date en gebruiksklaar) draait dubbel bij een andere hoster. Dit kan betekenen dat er een extra licentie moet worden afgenomen. Dit voorkomt zowel discontinuïteit in geval van faillissement van de clouddienstverlener als faillissement van de hoster. Of u beiden aanpakt, hangt af van hoever u wilt gaan en in hoeverre uw bedrijfsvoering afhankelijk is van de data en applicatie.

Er moet wel een kanttekening gemaakt worden bij bovenstaande oplossingen. Uw data moet migreerbaar zijn. Als er sprake is van een vendor lock-in wordt het lastig de data uiteindelijk over te zetten naar een applicatie van een andere clouddienstverlener. Vendor lock-in is
het verschijnsel dat een klant zo zeer afhankelijk wordt van een leverancier dat het contract beeïndigen of overstappen niet langer mogelijk is zonder grote (financiële) gevolgen. Het is dan ook van belang dat u bij het uitzoeken van een applicatie hiermee rekening houdt.

Data en hosting

Indien u gebruikmaakt van een clouddienst, dan zult u vaak ook uw data in de cloud bewaren. Met andere woorden, u voert uw data in en deze wordt niet op uw eigen server opgeslagen, maar op een server van de clouddienstverlener. De server kan in eigendom zijn van de dienstverlener of van een derde partij (de hostingprovider). Om de keten nog langer te maken: de server staat weer in een rack en dit rack staat in een datacenter. Dat datacenter is mogelijk weer van een andere partij.

Domeinnamen

Zonder een domeinnaam, kan een clouddienst niet benaderd worden. Om bij bedreiging van de continuïteit controle te houden over de relevante domeinnamen, kan er voor één van de volgende oplossingen gekozen worden: (1) er kan een pandrecht gevestigd worden op de domeinnamen, (2) de domeinnamen kunnen worden overgedragen aan de aparte economische entiteit of, indien de domeinnamen niet van de clouddienstverlener zijn maar van de klant, dan (3) moet de klant er enkel voor zorgen dat hij de domeinnaam ook in de praktijk onder controle heeft. Hieronder worden de oplossingen toegelicht.

Een domeinnaam is te kwalificeren als een vorderingsrecht op naam van de domeinnaamhouder jegens de “registry”. Voor de .nl domeinnamen is de registry de SIDN. Voor verpanding vereist de wet dat hetgene dat verpand wordt overdraagbaar is. Indien het niet overdraagbaar is, kan het ook niet verpand worden.

Een vorderingsrecht is overdraagbaar op grond van de wet en kan dus ook verpand worden. De Stichting Continuïteit Internetdiensten kan met de dienstverlener overeenkomen dat de dienstverlener de domeinnamen aan haar verpandt. De domeinnamen mogen dan niet zonder de toestemming van de Stichting Continuïteit Internetdiensten worden overgedragen.

Het is wel zo dat een pandrecht alleen als zekerheidsrecht is bedoeld voor een geleende geldsom. Als die voldaan wordt, eindigt de macht van de Stichting Continuïteit Internetdienstenover over de domeinnaam.

Om een pandrecht te vestigen moet er een akte van verpanding worden opgemaakt. Daarin staan het object van verpanding en de geleende geldsom. De akte moet door de notaris worden gedeponeerd of moet worden ingeschreven bij de Belastingdienst. Wettelijk gezien moet degene jegens wie het vorderingsrecht geldt ook op de hoogte worden gesteld van de verpanding. De SIDN heeft hier een eigen procedure voor (lees hier meer over deze procedure).

Naast verpanding kan er gekozen worden voor overdracht van de domeinnamen aan een andere economische entiteit zoals dat ook bij software kan (zie ook ons eerdere artikel hier).

De domeinnaam kan natuurlijk ook van de klant zijn en niet van de dienstverlener. Dan moet de klant er enkel voor zorgen dat hij de domeinnaam daadwerkelijk in zijn macht heeft. Oftewel, de klant moet beschikken over de autorisatie-code van zijn domeinnaam en moet in staat zijn om de DNS-verwijzingen van de domeinen te wijzigen.

Domeinnamen

Naast verpanding kan er gekozen worden voor overdracht van de domeinnamen aan een andere economische entiteit zoals dat ook bij software kan (zie ook ons eerdere artikel hier).

Software

Op de software die onderdeel uitmaakt van de clouddienst rust auteursrecht. Om deze software te mogen gebruiken, heeft de afnemer een gebruiksrecht (ook wel ‘licentie’) nodig. Wat gebeurt er met dit gebruiksrecht op het moment dat de dienstverlener failliet gaat of de continuïteit anderszins wordt bedreigd?

Na het zogeheten Berzona-arrest uit 2006 is er veel onrust ontstaan over de positie van een licentiehouder in het geval van een faillissement van de toeleverancier. Uitgaande van de meest recente rechtspraak lijkt de licentiehouder echter redelijk stevig in zijn schoenen te staan. In het geval van een faillissement kan een curator niet zomaar een licentie beëindigen. En ook als de curator besluit om de auteursrechten te verkopen aan een derde partij, kan hij de eerder verstrekte licenties niet zomaar negeren. Met enkel een gebruiksrecht op de software is de afnemer echter nog niet beschermd. Een clouddienst bestaat immers uit veel meer componenten. Zonder bijvoorbeeld hosting en onderhoud heeft een gebruiksrecht weinig zin. En dat is waar de Stichting Continuïteit Internetdiensten om de hoek komt kijken.

Ook de Stichting Continuïteit Internetdiensten heeft natuurlijk een recht nodig om de software te mogen gebruiken én om deze door te kunnen leveren. Het streven is daarbij om de positie van de stichting na het faillissement zo sterk mogelijk te maken. In dit kader moet onderscheid gemaakt worden tussen twee situaties.

Situatie 1: clouddiensverlener is rechthebbendde

Als het auteursrecht bij de clouddienstverlener ligt, dan zijn er de volgende drie continuïteitsoplossingen:

Een overdracht van het auteursrecht aan een andere/nieuwe (economische) entiteit. Er kan dan het beste gekozen worden voor een bv of stichting. Deze nieuwe entiteit geeft dan een licentie aan de dienstverlener én aan de Stichting Continuïteit Internetdiensten.
Een gedeeltelijke overdracht van het auteursrecht naar de Stichting Continuïteit Internetdiensten. Het voordeel hiervan is dat (net als in het vorige voorbeeld) de curator dit niet kan negeren. Uiteraard wordt slechts een klein stukje van het auteursrecht overgedragen naar de Stichting Continuïteit Internetdiensten. Alleen dát stukje dat nodig is om de continuïteitsregeling uit te kunnen voeren. Voor het overige berusten de auteursrechten bij de dienstverlener zelf.
Als laatste is er nog de mogelijkheid om een recht van vruchtgebruik te vestigen. Deze mogelijkheid wordt in de literatuur een aantal keer genoemd maar is nog nooit bevestigd door een rechter. Het voordeel van vruchtgebruik is dat het een beperkt recht is. Een beperkt recht kan niet zoals een normale licentie, beëindigd of genegeerd worden door de curator. Het nadeel is dat de rechter deze oplossing misschien als oneigenlijk gebruik van het recht ziet en het vruchtgebruik ongeldig verklaard.

Situatie 2: clouddienstverlener is geen rechthebbende

In het geval dat de clouddienstverlener enkel een licentie heeft voor haar gebruik van de software, dan kan de Stichting Continuïteit Internetdiensten ook een poging wagen een licentie te bemachtigen. Het heeft dan kostentechnisch de voorkeur om een licentie te krijgen die pas “geactiveerd wordt” op het moment dat continuïteit bedreigd wordt.

Software

Situatie 1: clouddiensverlener is rechthebbendde

Als het auteursrecht bij de clouddienstverlener ligt, dan zijn er de volgende drie continuïteitsoplossingen:

Een overdracht van het auteursrecht aan een andere/nieuwe (economische) entiteit. Er kan dan het beste gekozen worden voor een bv of stichting. Deze nieuwe entiteit geeft dan een licentie aan de dienstverlener én aan de Stichting Continuïteit Internetdiensten.
Een gedeeltelijke overdracht van het auteursrecht aan de Stichting Continuïteit Internetdiensten. Het voordeel hiervan is dat (net als in het vorige voorbeeld) de curator dit niet kan negeren. Er is immers geen sprake van een licentie maar van een overdracht. Uiteraard wordt slechts een klein stukje van het auteursrecht overgedragen naar de Stichting Continuïteit Internetdiensten. Alleen dát stukje dat nodig is om de continuïteitsregeling uit te kunnen voeren. Voor het overige berusten de auteursrechten bij de dienstverlener zelf.
Als laatste is er nog de mogelijkheid om een recht van vruchtgebruik te vestigen. Deze mogelijkheid wordt in de literatuur een aantal keer genoemd maar is nog nooit bevestigd door een rechter. Het voordeel van vruchtgebruik is dat het een beperkt recht is. Een beperkt recht kan niet zoals een normale licentie, beëindigd of genegeerd worden door de curator. Het nadeel is dat de rechter deze oplossing misschien als oneigenlijk gebruik van het recht ziet en het vruchtgebruik ongeldig verklaard.

Situatie 2: dienstverlener geen rechthebbende

Organisatiestructuur

Voordat de continuïteitsregeling kan worden ingericht is een inventarisatie van de dienstverlener én van de clouddienst zelf nodig. Van belang is op de eerste plaats om te beoordelen hoe de ondernemingsstructuur van de dienstverlener eruitziet. Is er bijvoorbeeld sprake van een vennootschap onder firma (vof) of besloten vennootschap? Is er sprake van een holdingstructuur of is er al sprake van een afzonderlijke rechtspersoon waar de ontwikkeling plaatsvindt of waar de intellectuele eigendomsrechten in zijn ondergebracht?

Essentiële bedrijfsonderdelen

In de continuïteitsregeling moet rekening worden gehouden met alle bedrijfsonderdelen die essentieel zijn in het kader van de geleverde clouddienst. Denk hierbij op de eerste plaats aan de intellectuele eigendomsrechten die rusten op de clouddienst. Maar denk ook aan licenties op standaardsoftware van derden die in de clouddienst zijn geïntegreerd of die daarmee gekoppeld zijn. Of aan de servers waarop de software geïnstalleerd is. Het uiteindelijke doel is om zakelijke risico’s en essentiele bedrijfsonderdelen van elkaar te scheiden.

Het voorgaande kan bijvoorbeeld bewerkstelligd worden door bepaalde bedrijfsonderdelen onder te brengen in een aparte juridische entiteit (bijvoorbeeld een holding of een entiteit ten behoeve van research en development). Maar soms zijn er ook praktische maatregelen mogelijk om essentiële bedrijfsonderdelen tegen zakelijke risico’s te beschermen.

Governance

Er zal ook gekeken moeten worden hoe het bestuur (of governance) van de onderneming in elkaar zit. Het is van belang om te weten met wie rekening moet worden gehouden naast het statutaire bestuur van de onderneming. Is er bijvoorbeeld een ondernemersraad? Wie zijn de aandeelhouders? Wat is hun bevoegdheid? Is er een ander orgaan zoals een raad van commissarissen?

Voorgaande punten zijn van belang om later te kunnen beoordelen of en hoe essentiële bedrijfsonderdelen veiliggesteld kunnen worden. Kunnen de bedrijfsonderdelen herverdeeld worden binnen de huidige entiteiten en zo veiliggesteld worden? Of is het nodig om nieuwe entiteiten te creëren. En misschien blijkt uit de inventarisatie dat essentiële bedrijfsonderdelen al veilig zijn ondergebracht in een entiteit die weinig tot geen risico’s loopt.

Moet er nog herverdeeld worden, dan is het noodzakelijk om inzicht te hebben in het verdienmodel en het governancemodel. Anders loopt de herverdeling waarschijnlijk stuk omdat het niet aansluit bij het verdienmodel of omdat een bestuurder dwars gaat liggen.

Structuur van de organisatie

Essentiële bedrijfsonderdelen

Governance

De regeling

Continuïteit in de cloud vergt een goede continuïteitsregeling. Natuurlijk kan de clouddienstverlener niet op haar eigen houtje garanderen dat de clouddienst blijft doordraaien ondanks een faillissement. Daarom moet er een derde onafhankelijke entiteit betrokken worden om deze taak te vervullen (de Stichting Continuïteit Internetdiensten).

De Stichting Continuïteit Internetdiensten sluit een raamovereenkomst met de clouddienstverlener over hoe de continuïteit het beste geregeld kan worden. De inhoud van deze overeenkomst zal afhangen van de soort dienst (IaaS, PaaS of SaaS), waar het eigendom ligt van de verschillende onderdelen binnen de onderneming en waartoe de clouddienstverlener bereid is.

De afnemer kan vervolgens toetreden tot de mantelovereenkomst middels een derdenbeding. Een derdenbeding houdt het volgende in: een bepaling (beding) in een overeenkomst waar een derde, dus een partij die geen partij is bij de betreffende overeenkomst, een beroep op kan doen en hetgeen de derde aldus (bijvoorbeeld door een verklaring) kan aanvaarden. Het derdenbeding hoeft alleen aanvaard te worden door de afnemer. De afnemer wordt hier ook wel begunstigde genoemd, daar hij of zij begunstigde is van de overeenkomst.

Op het moment dat de continuïteit daadwerkelijk in gevaar is, kan de afnemer aankloppen bij de Stichting Continuïteit Internetdiensten op grond van het derdenbeding. De stichting zal zich vervolgens inzetten om de diensten nog een poosje draaiend te houden.

Jurist, fiscalist en register valuator

Over het algemeen is er niet alleen juridische kennis nodig om de continuïteitsregeling in te richten, maar ook een fiscalist en/of accountant. Zo moet goed gekeken worden naar de eventuele gevolgen voor een aanspraak onder de WBSO-regeling of Innovatiebox. Er kunnen ook waarderingsvraagstukken spelen, en daarbij is er (soms) een register valuator nodig.

Kan het makkelijker?

Ja en nee. Het antwoord is ‘ja’ als de afnemer op zoek is naar een gedeeltelijke oplossing die, bijvoorbeeld, het direct offline gaan van de dienst bij het faillissement van de dienstverlener voorkomt. Denk dan aan het doordraaien van een VPS. Dit kan bewerkstelligd worden met een contract tussen de afnemer en de ingeschakelde hostingserviceprovider.

Het antwoord is echter ‘nee’ als u de continuïteit volledig wil waarborgen. Met enkel het borgen van de hosting is de clouddienst namelijk lang niet altijd gered. Wat gebeurt er bijvoorbeeld wanneer er een essentiële beveiligingsupdate moet worden doorgevoerd? De afnemer zal hier in de meeste gevallen zelf niet toe in staat zijn. En hoe wordt er omgegaan met koppelingen met externe software? Hoe zijn de licenties daarvoor bijvoorbeeld geborgd?

Om een volledig dekkende continuïteitsregeling op te kunnen zetten, zal altijd naar de specifieke situatie en naar de organisatiestructuur van de clouddienstverlener gekeken moeten worden.

De regeling

Jurist, fiscalist en register valuator

Kan het makkelijker?

Om een volledig dekkende continuïteitsregeling op te kunnen zetten, zal altijd naar de specifieke situatie en naar de organisatiestructuur van de clouddienstverlener gekeken moeten worden.

De uitdaging

Van onze tekstverwerker tot patiëntendossiers, vrijwel alles draait tegenwoordig in de cloud. Daarmee worden we met zijn allen steeds afhankelijker van externe toeleveranciers. Het is dan ook niet vreemd dat IT-diensten in de rechtsspraak als nutsvoorzieningen worden bestempeld. En toch, heeft u al een acceptabel antwoord op de vraag: ‘wat als mijn clouddienstverlener failliet gaat?’ En wat gebeurt er wanneer hij de spreekwoordelijke stekker uit de dienst trekt? In deze reeks artikelen geven wij – in verschillende delen – antwoord op de vraag hoe continuïteit van clouddienstverlening gewaarborgd kan worden.

Wat verstaan we onder een clouddienst?

Met een clouddienst doelen wij op via het internet bereikbare diensten. Zowel private als public. Uiteraard kennen we nog veel meer benamingen zoals IaaS, PaaS en SaaS. Alle verschillende soorten clouddiensten hebben als gemene deler dat ze bestaan uit grofweg de volgende componenten: een internetaansluiting, elektriciteit, (virtuele) hardware, een datacenter, software (applicatie- en besturingssoftware), data en de mensen die de verschillende componenten bouwen, beheren en onderhouden.

Werken in de cloud

De standaard argumenten tegen het gebruik van de clouddienst gaan vaak over het (niet) beschikbaar zijn, beveiliging en privacy. Bij beschikbaarheid kan het gaan om het tijdelijk niet beschikbaar zijn bijvoorbeeld vanwege een fout in de software of een probleem met de internetverbinding. Tegen dergelijke risico’s kan men zich wapenen door het maken van duidelijke contractuele afspraken, bijvoorbeeld in een Service Level Agreement (SLA). Bij het overstappen naar een andere leverancier kunnen zich ook problemen voordoen die leiden tot het niet-beschikbaar zijn van data of de dienst. Om dit te voorkomen is het noodzakelijk om een goede exit-regeling te treffen. Lastiger is het om maatregelen te nemen tegen het risico op permanente onbeschikbaarheid van de dienst, met name in de situatie waarin de dienstverlener failliet wordt verklaard.

Wat als mijn dienstverlener failliet gaat?

Een SLA of een exit-regeling kunnen de afnemer van een clouddienst niet beschermen tegen de gevolgen van een faillissement van de dienstverlener. Waarom niet? Omdat de dienstverlener niet langer de overeenkomst kan nakomen en de curator dat niet hoeft als hij dat niet in het voordeel van de schuldeisers acht. Is dat kort door de bocht? Een beetje, maar toch is het wel waar het in de meeste gevallen op neerkomt. Om in deze situaties toch continuïteit te kunnen borgen, is een uitgebreidere regeling nodig.

De uitdaging

Van onze tekstverwerker tot patiëntendossiers, vrijwel alles draait tegenwoordig in de cloud. Daarmee worden we met zijn allen steeds afhankelijker van externe toeleveranciers. Het is dan ook niet vreemd dat IT-diensten in de rechtsspraak als nutsvoorzieningen worden bestempeld. En toch, heeft u al een acceptabel antwoord op de vraag: ‘wat als mijn clouddienstverlener failliet gaat?’ En wat gebeurt er wanneer hij de spreekwoordelijke stekker uit de dienst trekt? In deze artikelen geven wij – in verschillende delen – antwoord op de vraag hoe continuïteit van clouddienstverlening gewaarborgd kan worden.