SaaS Exit Strategieën
Auteur: Bas Groot Hulze
Studentnummer: 11165871
E-mail: bas.groot.hulze@gmail.com
Onderwijsinstelling: Universiteit van Amsterdam – Amsterdam Business School Opleiding: Amsterdam IT Audit Program (AITAP)
Datum: 1 augustus 2018
2
Inhoudsopgave
Voorwoord ... 5
Samenvatting en eindconclusie ... 6
1. Inleiding ... 7
1.1. Aanleiding tot het onderzoek ... 7
1.2. Conceptueel model ... 7
1.2.1. Doelstelling ... 7
1.2.2. Vraagstelling ... 7
1.3. Onderzoeksstrategie ... 8
1.3.1. Onderzoeksmethoden ... 8
1.3.2. Afbakening van het onderzoek ... 12
2 Begripsbepaling SaaS exit strategieën ... 13
2.1 Inleiding ... 13
2.2 Verantwoording ... 13
2.3 Definities... 13
2.4 Conclusie ... 16
3 Redenen initiëren SaaS exit ... 17
3.1 Inleiding ... 17
3.2 Verantwoording ... 17
3.3 Beëindiging overeenkomst ... 17
3.4 Redenen initiatie SaaS exit ... 18
3.5 Impact van de manier van beëindigen ... 19
3.6 Conclusie ... 19
4 Risico’s ... 20
4.1 Inleiding ... 20
4.2 Verantwoording ... 20
4.3 Belang applicatie(gegevens) voor risicoanalyse ... 20
4.4 Risk Appetite Statement... 21
4.5 Inherente risico’s gebruik van SaaS-diensten ... 21
4.6 Risico’s SaaS exit ... 22
4.6.1. Continuïteit ... 23
4.6.2. Snelle transitie ... 23
4.6.3. Minimale verstoring diensten conform servicelevels ... 24
4.6.4. Zonder dataverlies ... 24
4.6.5. Tegen redelijke kosten ... 25
3
4.7 Risico’s in het referentiemodel ... 26
4.8 Conclusie ... 27
5 Mitigerende maatregelen ... 28
5.1 Inleiding ... 28
5.2 Verantwoording ... 28
5.3 Mitigerende maatregelen per risico ... 28
5.2.1. Continuïteit ... 28
5.2.2. Snelle transitie ... 29
5.2.3. Minimale verstoring dienstverlening... 30
5.2.4. Volgens overeengekomen servicelevels ... 30
5.2.5. Zonder dataverlies ... 31
5.2.6. Tegen redelijke kosten ... 31
5.2.7. Vendor Lock In ... 32
5.2.8. Ease of contracting ... 32
5.4 Maatregelen voor in het referentiemodel ... 33
5.5 Conclusie ... 33
6 Conceptueel referentiemodel ... 35
6.1 Inleiding ... 35
6.2 Verantwoording ... 35
6.3 Mitigerend effect maatregelen in conceptueel referentiemodel ... 35
6.4 Conclusie ... 36
7 Praktijktoetsing ... 37
7.1 Inleiding ... 37
7.2 Verantwoording ... 37
7.3 Analyse resultaten casestudy ... 39
7.4 Aanpassingen in het conceptueel referentiemodel ... 41
7.5 Conclusie ... 41
8 Conclusie ... 43
8.1 Inleiding ... 43
8.2 Beantwoording centrale vraagstelling ... 43
9 Aanbeveling voor verder onderzoek en persoonlijke reflectie ... 45
9.1 Inleiding ... 45
9.2 Aanbeveling voor verder onderzoek ... 45
9.3 Persoonlijke reflectie ... 45
Literatuurlijst ... 47
BIJLAGE 1 COSO ERM ... 51
4
BIJLAGE 3 Conceptueel referentiemodel SaaS exit strategie ... 54 BIJLAGE 4 Gespreksverslagen interviews ... 55 BIJLAGE 5 Referentiemodel SaaS exit strategie ... 66
5
Voorwoord
De band The Eagles geven in hun nummer Hotel California aan: “You can check out anytime you like, but you can never leave”. Hetzelfde kan gelden voor het gebruik maken van SaaS-diensten zonder goede SaaS exit strategie. Deze scriptie heeft ten doel bij te dragen aan bewustwording rondom SaaS exits en bijbehorende strategieën om de exit op een adequate manier mogelijk te maken. Deze scriptie is de afronding van mijn studie aan de Universiteit van Amsterdam genaamd Amsterdam IT Audit Program (AITAP). Met veel plezier kijk ik terug op het volgen van de colleges en de vele contacten die ik heb opgedaan. En nu dus de grand finale…
Dank ben ik aan velen verschuldigd, zeker aan Koos Wolters voor de begeleiding en voor de nodige kritische noten. Naast alle docenten wil ik in het bijzonder Annelies Vethman bedanken. Ook wil ik expliciet iedereen bedanken die direct of indirect heeft meegewerkt aan dit onderzoek.
De meeste dank ben ik echter verschuldigd aan mijn vrouw, kinderen, familie en vrienden. Zij hebben mij de tijd gegund om de studie te kunnen volgen en nu te kunnen afronden.
Verder wil ik uiteraard mijn werkgever bedanken voor het vertrouwen, het mogelijk maken om de studie te volgen en het beschikbaar stellen van de middelen.
Op naar de volgende uitdaging! Vleuten, juli 2018
6
Samenvatting en eindconclusie
Het gebruik van SaaS-diensten is iets dat in de laatste jaren is opgekomen en steeds meer wordt geadopteerd door organisaties. Vanuit verschillende hoeken wordt echter gewezen op het belang van het hebben van een SaaS exit strategie. Wat echter ontbreekt, zijn richtlijnen voor de bepaling van de adequaatheid van een SaaS exit strategie.
De doelstelling van dit onderzoek is om inzicht te geven waar een SaaS exit strategie aan moet voldoen. Daarbij rekening houdend met de risico’s die bedrijven lopen bij het beëindigen van overeenkomsten met een CSP voor uitbestede werkzaamheden. Meer specifiek gaat het om de aspecten die een rol spelen bij het bepalen van de adequaatheid van een SaaS exit strategie aan de hand van een referentiemodel door de IT-auditor. Om de doelstelling te kunnen beantwoorden kent dit onderzoek de volgende centrale vraag:
Welk referentiemodel kan de IT-auditor gebruiken voor het bepalen van de adequaatheid van een SaaS exit strategie?
Er zijn verschillende redenen geïdentificeerd voor een organisatie om een SaaS exit te initiëren. De aanleiding heeft invloed op de te selecteren SaaS exit strategie. Er dienen daarom meerdere SaaS exit strategieën te zijn. Een SaaS exit strategie heeft ten doel om risico’s die zich kunnen manifesteren tijdens de SaaS exit te mitigeren om zo verstoring van andere (bedrijfs-)processen te voorkomen. Middels bureauonderzoek is gezocht in de beschikbare bronnen naar voorkomende risico’s met betrekking tot SaaS en in het bijzonder met betrekking tot SaaS exits.
Ook is middels bureauonderzoek binnen de beschikbare bronnen gezocht naar maatregelen die de geïdentificeerde risico’s kunnen mitigeren. Aan de hand van de gefundeerde theoriebenadering is de confrontatie gemaakt tussen de geïdentificeerde risico’s en de mitigerende maatregelen. Met als gevolg een conceptueel referentiemodel voor de bepaling van de adequaatheid van een SaaS exit strategie.
Om het conceptueel referentiemodel te evalueren is dit als case middels een casestudy voorgelegd aan een aantal selectief gekozen experts uit de praktijk. De risico’s, de maatregelen en het model zijn gevalideerd en na het doorvoeren van een aantal wijzigingen is een referentiemodel tot stand gekomen dat door een IT-auditor gebruikt kan worden voor het bepalen van de adequaatheid van een SaaS exit strategie. Hierbij dient er wel rekening mee gehouden te worden dat zowel het opstellen van een SaaS exit strategie als het bepalen van de adequaatheid daarvan maatwerk is, en van geval tot geval zal verschillen. Uit de casestudy blijkt dat de belangrijkste aspecten ondervangen zijn in het model.
7
1. Inleiding
1.1. Aanleiding tot het onderzoek
Financiële instellingen zijn doorgaans behoudend in het meegaan met nieuwe ontwikkelingen, zoals bijvoorbeeld het gebruik maken van diensten uit de cloud. Toezichthouders spelen hier een belangrijke rol in. De Nederlandsche Bank (DNB) maakt zich in haar rol als toezichthouder in Nederland sterk voor financiële stabiliteit en meer in het bijzonder voor solide, integere en afwikkelbare financiële instellingen die hun verplichtingen en toezeggingen nakomen (DNB, 2017, “Missie en taken”, para. 2). DNB heeft in dit kader op 6 december 2011 een circulaire uitgedaan omtrent Cloud Computing. In deze circulaire stelt DNB Cloud Computing gelijk aan uitbesteding (DNB, 2011, p. 1).
De circulaire regelt onder meer dat onder toezicht staande ondernemingen een aantal afspraken op dienen te nemen in de overeenkomst met de cloud serviceprovider (CSP) (DNB, 2011, p. 2-3). Deze afspraken dienen onder meer betrekking te hebben op de wijze waarop wordt gewaarborgd dat de werkzaamheden na beëindiging van de overeenkomst weer door de uitbesteder zelf of door een andere derde kan laten uitvoeren.
Meer recente berichten geven een ontwikkeling aan in het standpunt van DNB. DNB heeft bijvoorbeeld afspraken gemaakt met CSP’s, zoals Microsoft en Google (DNB, 2013a, 2013b, 2016). Hierdoor zijn meer clouddiensten, en in het bijzonder SaaS-diensten, toegankelijk voor financiële instellingen. Waar bedrijven, zoals financiële instellingen, meer diensten uit de cloud gaan afnemen, is het onverminderd van belang voor deze bedrijven om er zeker van te zijn dat zij hun diensten kunnen terughalen uit de cloud of kunnen overdragen aan een andere CSP, zoals vereist voor financiële instellingen in de circulaire van DNB. Een van de maatregelen is het daartoe ontwikkelen van SaaS exit strategieën. Maar hoe kan een IT-auditor bepalen in hoeverre een SaaS exit strategie adequaat is?
1.2. Conceptueel model
1.2.1.
Doelstelling
Doelstelling van dit onderzoek is om inzicht te geven waar een SaaS exit strategie aan moet voldoen. Daarbij rekening houdend met de risico’s die bedrijven lopen bij het beëindigen van overeenkomsten met een CSP voor uitbestede werkzaamheden. Meer specifiek gaat het om de aspecten die een rol spelen bij het bepalen van de adequaatheid van een SaaS exit strategie aan de hand van een referentiemodel door de IT-auditor.
1.2.2.
Vraagstelling
De benodigde kennis om de doelstelling van het onderzoek te bereiken wordt geformuleerd in de vraagstelling. Om de hierboven geformuleerde doelstelling te kunnen beantwoorden kent dit onderzoek de volgende centrale vraag:
Welk referentiemodel kan de IT-auditor gebruiken voor het bepalen van de adequaatheid van een SaaS exit strategie?
8
De vraagstelling valt in de volgende onderzoeksvragen uiteen:
1. Wat zijn volgens de literatuur de specifieke kenmerken van SaaS-diensten en exit strategieën? Voor de invulling hiervan zijn er de volgende deelvragen geformuleerd:
a. Wat is SaaS en wat is een SaaS exit (strategie)?
b. Wat voor redenen zijn er om een SaaS exit te initiëren?
c. Welke risico’s loopt de uitbestedende organisatie bij een SaaS exit? d. Wat zijn potentiële maatregelen binnen een SaaS exit strategie?
e. In hoeverre kunnen deze maatregelen de geconstateerde risico’s mitigeren?
2. Hoe zou een conceptueel referentiemodel van een SaaS exit strategie op basis van de literatuur eruit kunnen zien?
a. Hoe wordt de bruikbaarheid van het conceptuele referentiemodel beoordeeld door experts vanuit de praktijk?
b. Welke aanpassingen aan het referentiemodel kunnen op basis van de confrontatie met de praktijk doorgevoerd worden?
1.3. Onderzoeksstrategie
1.3.1.
Onderzoeksmethoden
In de vakliteratuur (bijvoorbeeld ISACA, 2014a, p. 87), maar ook door een toezichthouder als DNB (zie paragraaf 1.1), wordt aangegeven dat het van belang is om een (SaaS) exit strategie te hebben. Er is echter weinig literatuur beschikbaar waar ingegaan wordt op (de adequaatheid van) een SaaS exit strategie. Er is in de literatuur daarentegen wel informatie beschikbaar over exits, exit plannen en exit strategieën. Veel van deze informatie is echter gericht op outsourcing. Over SaaS (exit) risico’s en mitigerende maatregelen is beperkt vakliteratuur beschikbaar. De informatie die beschikbaar is, heeft slechts betrekking op mogelijke onderdelen van een exit strategie en zijn daardoor niet als geheel bruikbaar voor het integraal bepalen van de adequaatheid van een SaaS exit strategie.
Om aan de doelstelling van dit onderzoek te kunnen voldoen, namelijk inzicht te geven waaraan een adequate SaaS exit strategie moet voldoen, is gekozen voor een combinatie van verschillende onderzoeksmethoden om tot een model te komen dat kan worden gebruikt voor de bepaling van de adequaatheid van een SaaS exit strategie door de IT-auditor.
Voor een beter begrip van de adequaatheid van een SaaS exit strategie kan gekeken worden naar het doel dat een exit strategie beoogt te bereiken. NIST (2003, p. 36) geeft aan dat een exit strategie ten doel heeft de afgenomen dienstverlening te kunnen beëindigen zonder verstoring van de andere processen. Er zijn, blijkens deze definitie, risico’s voor andere processen die zich kunnen manifesteren tijdens de uitvoering van een exit. De exit strategie heeft klaarblijkelijk ten doel deze risico’s te mitigeren.
Toegepast op SaaS bevat een SaaS exit strategie mitigerende maatregelen voor de risico’s die zich kunnen manifesteren tijdens een SaaS exit. In dit onderzoek zal daarom onderzocht worden welke risico’s een SaaS exit met zich meebrengt en welke mitigerende maatregelen daarvoor in de SaaS exit strategie opgenomen kunnen worden. Door confrontatie van deze risico’s met de mitigerende maatregelen wordt gestreefd te komen tot een model dat gebruikt kan worden voor de bepaling van de adequaatheid van een SaaS exit strategie. Dit model wordt vervolgens getoetst bij ter zake deskundige experts.
9 Bureauonderzoek
Aan de hand van bureauonderzoek (Verschuren en Doorewaard, 2015, p. 159) is een inventarisatie gemaakt van de bestaande data met betrekking tot risico’s en mitigerende maatregelen bij een SaaS exit. Bureauonderzoek is gekozen als onderzoeksstrategie omdat de onderzoeker daarbij gebruik maakt van door anderen geproduceerd materiaal, dan wel waarbij hij probeert via reflectie en het raadplegen van literatuur tot nieuwe inzichten te komen. Voor afzonderlijke risico’s en maatregelen is in de vakliteratuur, de media en op internet gepubliceerde meningen data beschikbaar. Een secundaire onderzoekstrategie (Verschuren en Doorewaard, 2015, p. 199 e.v.) is toegepast om de gevonden data te herordenen en vanuit het gezichtspunt van een SaaS exit strategie op kwalitatieve wijze te analyseren en interpreteren. Een en ander vanuit het oogpunt een overzicht te krijgen van de bekende risico’s en mitigerende maatregelen van een SaaS exit.
Een survey of een casestudy was ook een mogelijkheid geweest om gegevens te verzamelen met betrekking tot SaaS exits, risico’s en mitigerende maatregelen. Het aantal SaaS exits lijkt echter tot op heden beperkt en de bereidheid van organisaties om mee te werken is waarschijnlijk niet heel groot. Een voordeel van bureauonderzoek daarentegen is dat de onderzoeker snel over een groot aantal gegevens kan beschikken. Een nadeel is dat de onderzoeker moet roeien met de riemen die hij heeft; de (beperkt) beschikbare informatie is vaak voor andere doeleinden gemaakt dan waarvoor het in het kader van zijn onderzoek gebruikt wordt. Onder meer om dit risico te mitigeren zullen de resultaten van het bureauonderzoek voorgelegd worden aan experts ter validatie van de resultaten.
In hoofdstuk 2 wordt op basis van bureauonderzoek een definitie van de begrippen SaaS en SaaS exit strategie gegeven en andere aanverwante begrippen. Daarmee wordt antwoord gegeven op de deelvragen ‘Wat is SaaS en wat is een SaaS exit (strategie)?’
In het volgende hoofdstuk 3 is, teneinde een beter begrip te krijgen van SaaS-dienstverlening en SaaS exits, middels bureauonderzoek inzicht gegeven in de redenen die er kunnen zijn om een exit strategie ten uitvoer te brengen om daarmee antwoord te geven op de vraag ‘Wat voor redenen zijn er om een SaaS exit te initiëren?’.
In hoofdstuk 4 is middels bureauonderzoek antwoord gegeven op de deelvraag ‘Welke risico’s loopt de uitbestedende organisatie bij een SaaS exit?’.
In hoofdstuk 5 is middels bureauonderzoek antwoord gegeven op de vraag ‘Wat zijn potentiële maatregelen binnen een SaaS exit strategie?’.
In hoofdstuk 6 vindt de confrontatie van de risico’s en de mitigerende maatregelen plaats in een conceptueel referentiemodel waar tevens de deelvragen ‘In hoeverre kunnen deze maatregelen de geconstateerde risico’s mitigeren?’ en ‘Hoe zou een conceptueel referentiemodel van een SaaS exit strategie op basis van de literatuur eruit kunnen zien?’ worden beantwoord. Voor de confrontatie is gebruik gemaakt van de gefundeerde theoriebenadering als onderzoeksstrategie om te komen tot theorie ontwikkelend onderzoek.
Conceptueel model
10 Theorie ontwikkelend onderzoek
Het ontbreken van vakliteratuur omtrent de bepaling van de adequaatheid van een SaaS exit strategie is te beschouwen, binnen de kaders van het bereiken van de doelstelling van dit onderzoek, als een probleem in de theorievorming. Het probleem is namelijk dat er geen literatuur beschikbaar is die alle risico’s en mitigerende maatregelen bij een SaaS exit beschrijft. Laat staan dat er literatuur is die de bepaling van de adequaatheid van een SaaS exit strategie beschrijft.
Daarom is ervoor gekozen om middels het toepassen van theoriegericht onderzoek deze theorie te ontwikkelen om daarmee het ondervonden probleem op te lossen. Verschuren en Doorewaard (2015, p. 44) geven aan dat bij theoriegericht onderzoek (ook omschreven als theorie-ontwikkelend onderzoek) het gaat om het oplossen van een probleem in de theorievorming op een bepaald vakgebied.
Gefundeerde theoriebenadering
Meer specifiek binnen het theoriegerichte onderzoek is gekozen voor toepassing van de gefundeerde theoriebenadering als onderzoeksstrategie (Verschuren en Doorewaard, 2015, p. 188 e.v.): “een onderzoek dat middels deze benadering is uitgevoerd is te karakteriseren als een manier
om (…) door het voortdurend op elkaar betrekken (confronteren) van fenomenen te komen tot nieuwe theoretische inzichten.” De gefundeerde theoriebenadering heeft onder meer de volgende
kenmerken:
• Een consequente toepassing van procedures en technieken; • Het (kwalitatief) vergelijken van gegevens en concepten;
• Een inductieve werkwijze, in afwijking van een gebruikelijk dominante deductieve werkwijze; • Een zoekende houding van de onderzoeker.
Er is gekozen voor de gefundeerde theoriebenadering om de samenhang tussen de uit het bureauonderzoek verkregen risico’s en mitigerende maatregelen van SaaS exits te onderzoeken. Dit is gedaan door de risico’s en de mitigerende maatregelen consequent te kwalitatief te vergelijken (te confronteren). De gefundeerde theoriebenadering kent een inductieve werkwijze, waarbij op
11
basis van confrontatie van de beschikbare informatie (de lijsten met risico’s en maatregelen) nieuwe theoretische inzichten worden nagestreefd. Het resultaat van dit onderzoek zal een tabel zijn met daarin tegen elkaar afgezet de risico’s en de mitigerende maatregelen, waarbij per risico wordt aangegeven in hoeverre een maatregel een risico mitigeert. Deze invulling zal initieel door de onderzoeker op basis van de kennis en inzichten ingevuld worden die opgedaan zijn tijdens het bureauonderzoek. Hiermee wordt ook het antwoord gegeven op de deelvraag ‘In hoeverre kunnen deze maatregelen de geconstateerde risico’s mitigeren?’.
Het doel is om de beschikbare informatie over risico’s, mitigerende maatregelen en de verkregen tabel met daarin de mate waarin de mitigerende maatregelen risico’s mitigeren met betrekking tot (SaaS) exits te verzamelen en te integreren in een model dat gebruikt kan worden voor de bepaling van de adequaatheid van een SaaS exit strategie. Hiermee wordt tevens antwoord gegeven op de deelvraag ‘Hoe zou een conceptueel referentiemodel van een SaaS exit strategie op basis van de literatuur eruit kunnen zien?’.
Casestudy
Het uit toepassing van de gefundeerde theoriebenadering verkregen conceptuele referentiemodel zal in hoofdstuk 7, als onderdeel van een casestudy, in concreto als case, worden voorgelegd ter validatie aan een aantal experts die kennis hebben van aspecten die van belang zijn bij SaaS exit strategieën. De keuze voor een casestudy is gemaakt, in plaats van bijvoorbeeld een survey, is om meer diepte te bereiken bij de validatie en daardoor beter en gerichter op de eventuele opmerkingen in te kunnen gaan. Het gaat dus meer om een kwalitatieve validatie dan een kwantitatieve validatie.
“De casestudy is een onderzoek waarbij de onderzoeker probeert om een diepgaand en integraal inzicht te krijgen in een of enkele tijdruimtelijk begrensde objecten of processen”, aldus Verschuren en Doorwaard (2015, p 179). Kenmerken van een casestudy zijn onder meer:
• Een smal domein (een case); • Meer diepte dan breedte;
• Een selectieve ofwel strategische steekproef;
• Kwalitatieve gegevens en dito onderzoeksmethoden.
De feedback van de experts zal worden gebruikt om het model te verbeteren, aan te vullen en om de toepasbaarheid van het model te toetsen. Hiermee wordt antwoord gegeven op de deelvragen: ‘Hoe wordt de bruikbaarheid van het conceptuele referentiemodel beoordeeld door experts vanuit de praktijk?’ en ‘Welke aanpassingen aan het referentiemodel kunnen op basis van de confrontatie met de praktijk doorgevoerd worden?’.
In hoofdstuk 8 zal vervolgens het antwoord worden geformuleerd op de centrale vraagstelling van dit onderzoek, waarna er in hoofdstuk 9 aandacht is voor persoonlijke reflectie en aanbevelingen voor verder onderzoek.
Bronnen
Als bron is zoveel mogelijk gebruik gemaakt van de beschikbare vakliteratuur. Daarnaast is gebruik gemaakt van gepubliceerde meningen en opinies in openbare bronnen als het internet en daarop aanwezige forums en blogs (sociale media). Op basis van deze informatie gevonden opinies over de onderliggende achtergronden en oorzaken is een referentiemodel opgesteld dat als geheel getoetst zal worden bij selectief geselecteerde, ter zake deskundige personen. Zie de Literatuurlijst voor de bronverwijzingen.
12
1.3.2.
Afbakening van het onderzoek
Zoals de titel van het onderzoek al aangeeft gaat het over SaaS-diensten, en niet bijvoorbeeld over IaaS en PaaS. In hoofdstuk 2 staan de definities van deze begrippen beschreven. Uit de definities blijkt dat SaaS de grootste mate van afhankelijkheid van een CSP kent. Deze grote afhankelijkheid brengt een hoger risico met zich mee (Veldhuis, 2015, 3 juni) (Schaffer, 2014). Om redenen van beheersbaarheid en relevantie van het onderzoek en de specifieke aspecten van exit strategieën bij het gebruik van SaaS-applicaties heb ik er daarom voor gekozen om alleen SaaS binnen de scope te nemen.
Verder richt dit onderzoek zich, om wille van de beheersbaarheid, op Public Cloud oplossingen. Alhoewel er ook voor Private, Hybrid en Community cloud specifieke aandachtspunten zijn, ligt de focus specifiek op oplossingen die door meerdere gebruikers worden afgenomen.
Het COSO-model kent een vijftal stappen (zie Bijlage 1). Dit onderzoek richt zich met name op de activiteiten binnen de stap ‘Performance’. Zo worden bijvoorbeeld resultaten van eerdere stappen als de Risk Appetite Statement en de governance als een gegeven beschouwd. De totstandkoming hiervan vallen buiten de kaders van dit onderzoek.
Door risico’s op een meer generiek niveau te houden is enerzijds getracht een breed toepasbaar resultaat te verkrijgen en anderzijds is getracht om de omvang van het onderzoek beheersbaar te houden. Voor wat betreft de inschatting van de specifieke risico’s zal worden volstaan met de constatering dat elke organisatie dit voor zichzelf zal moeten bepalen. Ook zijn de personen aan wie de informatie verstrekt moet worden uiteraard organisatieafhankelijk.
13
2
Begripsbepaling SaaS exit strategieën
2.1 Inleiding
In dit hoofdstuk zijn de in dit onderzoek gehanteerde definities van SaaS-diensten en exit strategieën beschreven. Er wordt antwoord gegeven op de deelvraag: ‘wat is SaaS en wat is een SaaS exit (strategie)?’. De definities geven duidelijkheid omtrent wat met een begrip bedoeld wordt in dit onderzoek en daarnaast bieden de definities inzicht in relevante aspecten van een SaaS Exit Strategie.
2.2 Verantwoording
Voor de beantwoording van de deelvraag is gebruik gemaakt van bureauonderzoek. Het uitgangspunt bij dit deel van onderzoek is geweest om zoveel mogelijk gebruik te maken van algemeen geaccepteerde vakliteratuur. Binnen dit hoofdstuk (en voor zover mogelijk ook in het vervolg) is bij de definities gebruik gemaakt van drie toonaangevende instituten:
• ISACA houdt zich als onafhankelijke, non-profit, wereldwijde vereniging zich bezig met de ontwikkeling, acceptatie en gebruik van wereldwijd geaccepteerde, toonaangevende kennis en werkwijzen voor informatiesystemen.
• NIST heeft als missie om de Amerikaanse innovatie en het industriële concurrentievermogen te bevorderen door meetwetenschap, normen en technologie te bevorderen op manieren die de economische veiligheid verbeteren en onze levenskwaliteit verbeteren.
• NOA (sinds 2016 GSA geheten) is de branchevereniging en professionele instantie voor de wereldwijde sourcing-industrie.
2.3 Definities
OutsourcingOutsourcing - een formele overeenkomst met een derde partij voor het leveren van informatiesysteem (IS) of andere bedrijfsdiensten voor een onderneming (ISACA, 2014b, p. 177) Cloud computing
Zoals in Hoofdstuk 1 vermeld, ziet een toezichthouder als DNB Cloud Computing als een vorm van Outsourcing. Het National Institute of Standards and Technology (NIST, 2011) hanteert de volgende definitie: cloud computing is een model voor het mogelijk maken van een benaderbare, eenvoudige en on demand netwerktoegang tot een gedeelde pool van configureerbare computerverwerking resources (bijvoorbeeld netwerken, servers, opslag, applicaties en diensten) waar snel in kan worden voorzien en beschikbaar gemaakt met minimale managementinspanning of interactie met de dienstverlener. Het cloud model bestaat uit vijf essentiële karakteristieken, drie
dienstverleningsmodellen en vier implementatiemodellen.
Essentiële karakteristieken:
1. On-demand selfservice. Een klant kan zelfstandig diensten afnemen, zonder menselijke interactie met de dienstverlener;
2. Brede netwerk toegang. Capaciteiten zijn beschikbaar via het netwerk en toegankelijk via standaardmechanismen die het gebruik door heterogene thin- of thick clientplatforms bevorderen (bijv. mobiele telefoons, tablets, laptops en werkstations).
14
3. Resource pooling. De computerresources van de provider worden samengevoegd om meerdere consumenten te bedienen met behulp van een multi-tenant-model, waarbij verschillende fysieke en virtuele resources dynamisch worden toegewezen en opnieuw toegewezen op basis van de consumentenvraag. Er is een gevoel van locatieonafhankelijkheid doordat de klant over het algemeen geen controle of kennis heeft over de exacte locatie van de geleverde bronnen, maar mogelijk een locatie op een hoger niveau van abstractie (bijvoorbeeld land, staat of datacenter) kan specificeren. Voorbeelden van bronnen zijn opslag, verwerking, geheugen en netwerkbandbreedte.
4. Snelle elasticiteit. De omvang en aard van de afgenomen diensten kunnen snel worden op- en afgeschakeld;
5. Gemeten dienstverlening. Cloud systemen monitoren en rapporteren de afgenomen typen diensten, waarbij de klant voor het daadwerkelijk verbruik betaalt.
Er zijn drie dienstverleningsmodellen: Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS).
1. Infrastructure as a Service (IaaS).
De gebruiker heeft de mogelijkheid om verwerkingscapaciteit, opslag, netwerken en andere fundamentele computerdiensten af te nemen, waar de gebruiker software op kan draaien waaronder operating systemen en applicaties. De gebruiker heeft geen controle over de onderliggende cloud infrastructuur, maar heeft wel controle over operating systemen, opslag en applicaties.
2. Platform as a Service (PaaS).
De gebruiker heeft de mogelijkheid om op de cloud infrastructuur zelfgecreëerde of aangeschafte applicaties te draaien. De gebruiker heeft geen controle over de onderliggende cloud infrastructuur, inclusief het netwerk, de servers, de operating systems of de opslag. 3. Software as a Service (SaaS)
De gebruiker heeft de mogelijkheid om gebruik te maken van de applicaties van de dienstverlener die draaien op een cloud infrastructuur. De gebruiker heeft geen beheer of controle over de onderliggende cloud infrastructuur, waaronder het netwerk, de servers, de operating systemen of zelfs de individuele applicatie mogelijkheden, met de potentiële uitzondering van beperkte gebruiker specifieke applicatie configuratie instellingen.
In onderstaande figuur 2 is, ter illustratie, een overzicht gegeven van de verantwoordelijkheden voor de Service Provider en de afnemer van Clouddiensten voor de verschillende dienstverleningsmodellen binnen Cloud Computing in vergelijking met Packaged Software.
15
Figuur 2 Cloud Computing en de dienstverleningsmodellen. Implementatiemodellen:
1. Private cloud. De cloud infrastructuur wordt beschikbaar gesteld voor exclusief gebruik door een organisatie;
2. Community cloud. De cloud infrastructuur wordt beschikbaar gesteld voor exclusief gebruik door een groep van gebruikers;
3. Public cloud. De cloud infrastructuur wordt beschikbaar gesteld voor gebruik voor openbaar gebruik;
4. Hybrid cloud. De cloud infrastructuur is een samenstelling van twee of meer specifieke cloud infrastructuren (private, community, or public).
SaaS Exit Strategieën
Voor SaaS Exit Strategieën is in de literatuur beperkt informatie beschikbaar. ISACA (2014a, p. 87) geeft bijvoorbeeld weliswaar aan dat een (cloud) exit strategie een belangrijke mitigerende maatregel is, maar is verder terughoudend in de beschrijving van de exit strategie. Slechts in algemene termen omschrijft ISACA de eisen aan een exit strategie en besteedt dan met name aandacht aan de contractuele bepalingen (2014a, p. 243). Een specifieke definitie van een SaaS exit strategie ontbreekt evenals een model om te bepalen in hoeverre een SaaS exit strategie adequaat is. De vergelijking met exit strategieën, zoals gebruikt bij meer traditionele uitbestedingen, levert mogelijk meer inzicht in de definitie en de relevante aspecten van een adequate SaaS exit strategie. Exit Plan
De begrippen exit strategie en exit plan worden in de literatuur nog weleens door elkaar gebruikt. In het kader van dit onderzoek wordt de definitie van de National Outsourcing Association gebruikt (NOA, 2015, p. 12): Het plan gemaakt door de zittende CSP voor het beëindigen van het contract bij het verlopen van het contract of bij specifieke beëindiging. Het gaat hierbij om het overdragen van de diensten naar de nieuwe CSP of naar de gebruiker van de diensten.
Exit Strategie
Het NIST (2003, p. 36) geeft de volgende beschrijving van (het doel van) een exit strategie: exit strategieën moeten worden ontwikkeld om ervoor te zorgen dat de organisatie de afgenomen dienstverlening kan beëindigen zonder andere processen binnen de organisatie te verstoren. De
16
exit strategie dient te voorzien in actieplannen voor normale, geplande beëindigingen, zoals bij het verstrijken van de looptijd van de dienstovereenkomst; en onverwachte beëindigingen, zoals bij faillissement van de dienstverlener; en eventueel andere gespannen beëindigingen, zoals bij slechte dienstverlening door de CSP.
Verschil tussen Exit Plan en Exit Strategie
Het verschil tussen een exit plan en een exit strategie zit met name in de opsteller ervan: bij een exit plan is dat de huidige CSP van de diensten, bij een exit strategie is dat de gebruiker van de diensten. In dit onderzoek zal de hierboven gedefinieerde omschrijving van een (outsourcing) exit strategie worden gehanteerd waarbij de toepassing alleen SaaS-dienstverlening betreft.
2.4 Conclusie
In dit hoofdstuk is het antwoord op de deelvraag ‘wat is SaaS en wat is een SaaS exit (strategie)?’ gegeven. SaaS is een dienstverleningsmodel binnen Cloud Computing, waarbij de afnemer van de dienst alle verantwoordelijkheid voor het voorzien in en managen van de onderliggende
resources. Een SaaS Exit Strategie moet worden ontwikkeld om ervoor te zorgen dat de
organisatie de afgenomen dienstverlening kan beëindigen zonder processen binnen de organisatie te verstoren.
17
3
Redenen initiëren SaaS exit
3.1 Inleiding
Dit hoofdstuk geeft antwoord op de deelvraag: ‘wat voor redenen zijn er om een SaaS exit te initiëren?’. Op basis van bureauonderzoek geeft dit hoofdstuk meer inzicht in het begrip SaaS exit door een overzicht te geven van de manieren waarop een overeenkomst tussen een CSP en een afnemer kan eindigen. Daarnaast geeft het meer specifiek aan wat voorkomende redenen zijn voor het initiëren van een SaaS exit dan wel wat de redenen zijn voor het hebben van een SaaS exit strategie.
3.2 Verantwoording
In dit hoofdstuk zijn de resultaten van het verrichte bureauonderzoek weergegeven. Gebruik is gemaakt van de beschikbare vakliteratuur, onder meer via de universiteitsbibliotheek, en uitgaven van algemeen erkende instituten, zoals NIST, NOA en ISACA. Omdat de op deze manier verkregen informatie maar deels beantwoordt aan de vraag, is, ten behoeve van een concretere aanvulling vanuit de praktijk, verder gezocht op het internet en social media naar artikelen en gepubliceerde meningen van personen die werkzaam zijn in het vakgebied. Alhoewel de gegeven overzichten en modellen van deze personen wellicht niet volledig en of wetenschappelijk gevalideerd zijn, geven ze wel meer inzicht in de problematiek en voldoet het resultaat daarmee aan de doelstelling van dit hoofdstuk, namelijk meer inzicht te geven in de redenen om een SaaS exit te initiëren. Een en ander heeft geleid tot de opvatting dat, op dit moment, de relevante, beschikbare informatie met betrekking tot SaaS exit strategieën is verzameld en verwerkt in dit onderzoek.
3.3 Beëindiging overeenkomst
Voor het gebruik van een public cloud SaaS-dienstverlening wordt een overeenkomst gesloten tussen de gebruiker en de CSP. Deze overeenkomst zal op enig moment eindigen. Van Dun, Van Bruggen, De Lange (2002, p. 52) geven drie manieren aan waarop een IT-overeenkomst kan worden beëindigd, los van een vooraf overeengekomen einddatum:
1. Met wederzijds goedvinden;
2. Beëindiging van rechtswege of op grond van contractuele bepalingen; 3. Ontbinding op initiatief van een van de partijen.
Dit is in lijn met de eerder in dit onderzoek gehanteerde definitie van een exit strategie van NIST (2003, p. 36), die naast het verstrijken van de looptijd van de dienstovereenkomst ook onverwachte beëindigingen, zoals bij faillissement van de dienstverlener of bijvoorbeeld slechte dienstverlening door de CSP meeneemt.
De NOA (2014, p. 18) geeft aan dat een exit strategie alleen effectief is als deze beschikbaar is voor de gebruiker op het juiste moment. Uitgebreide exit management bepalingen in een contract (zoals bijvoorbeeld het exit plan) zijn van weinig waarde voor de gebruiker als de gebruiker voor een lange periode vastzit aan de overeenkomst. Belangrijk is het, volgens de NOA, om in het contract te adresseren wat de omstandigheden zijn waaronder de overeenkomst kan worden beëindigd. Dit zijn volgens de NOA:
• Beëindiging wegens een bepaalde oorzaak (Termination for cause); • Beëindiging wegens insolventie (Termination for insolvency);
18 • Andere beëindigingsrechten;
• Vervaldatum (expiry).
3.4 Redenen initiatie SaaS exit
Na in de vorige paragraaf het overzicht te hebben gegeven op wat voor manieren een IT-overeenkomst kan eindigen, geeft deze paragraaf inzicht in potentiële redenen voor een organisatie om over te gaan tot beëindiging van de SaaS-dienstverlening. Hierbij is gebruik gemaakt van diverse bronnen uit het vakgebied om een beeld te schetsen van het palet aan motieven dat een gebruiker van Clouddiensten kan hebben.
Gartner, bij monde van Hilgendorf, geeft bijvoorbeeld in zijn blog (2013, 18 september) een aantal voorbeelden van redenen waarom een gebruiker SaaS-diensten zou kunnen willen beëindigen (naast het faillissement van de CSP):
• De diensten van de CSP zijn minder betrouwbaar dan geventileerd in SLA’s, contracten en uitgesproken verwachtingen;
• De relatie met de CSP is slecht geworden;
• (Eenzijdige) veranderingen in de servicelevels door de CSP; • Verandering in de eigenaar van de CSP;
• Prijsverhogingen;
• (Eenzijdige) veranderingen in voorwaarden (terms and conditions); • Expiratie van de enterprise overeenkomst of het contract;
• Gebrek aan support;
• Gegevens-, veiligheids- of privacy schending (Data, security or privacy breach); • Onvermogen van de CSP om competitief te blijven met industry features; • Herhaalde of langdurige dienstonderbrekingen;
• Gebrek aan compensatie voor storingen of niet geleverde diensten; • Verandering in de interne aansturing, strategie of richting van de CSP.
Ook ISACA (2014, p.59-60) geeft aan dat er specifieke risico’s kleven aan een het gebruik van een CSP. Het zich manifesteren van die risico’s kan ertoe leiden dat de afnemer van cloud diensten een exit zal willen of moeten initiëren. Een selectie uit de genoemde aspecten:
• SLA-performance • Security
• Application Patch Management
• Visibility into software systems development life cycle (SDLC) • Identity and access management (IAM)
• Broad Exposure of applications
• Lack of control of the release management process • Browser vulnerabilities
Veldhuis (2015, 3 juni) geeft in zijn blog aan dat grote CSP’s zoals Amazon, Azure en Google in hun contracten voorwaarden hebben opgenomen waarmee ze eenzijdig de overeenkomsten en servicelevels kunnen wijzigen. De overeenkomst mag bijvoorbeeld eenzijdig door de Cloud Service Provider (CSP) worden beëindigd zonder opgaaf van reden. In andere stukken staat dat het Service Level Agreement door de CSP mag worden gewijzigd.
Resumerend geeft bovenstaande aan dat er, gedurende het gebruik van de SaaS-dienst¸ veranderingen kunnen optreden in de dienstverlening, in de omstandigheden en of de
19
verwachtingen die een afnemer van de afgenomen SaaS-diensten heeft. De veranderingen kunnen aanleiding zijn voor een organisatie om het contract met de CSP te willen beëindigen.
3.5 Impact van de manier van beëindigen
De in de vorige paragraaf beschreven redenen kunnen aanleiding zijn voor een gebruiker van SaaS-diensten om de SaaS-overeenkomst te willen beëindigen. De specifieke aanleiding en de van toepassing zijnde contractuele voorwaarden kunnen bepalend zijn voor de mogelijkheden en omstandigheden waarbinnen de beëindiging eventueel plaats kan vinden.
• Bij een vooraf overeengekomen einddatum (expiry) geeft dit de afnemer de mogelijkheid zijn exit strategie van tevoren te bepalen.
• Bij bijvoorbeeld slechte dienstverlening door de CSP kan de afnemer zelf het initiatief nemen en meer het moment bepalen om de overeenkomst te beëindigen, het is echter afhankelijk van de contractuele bepalingen (termination for cause, convenience, of andere rechten) welke mogelijkheden daartoe zijn. In deze gevallen kan de beschikbare tijd ruimer zijn dan in het geval van het faillissement van de CSP.
• Bij een faillissement (termination for insolvency) zal er weinig tijd zijn om de exit, voor wat betreft bijvoorbeeld de overdracht van data en eventueel de SaaS-dienst, zelf te kunnen regelen. Een sprekend voorbeeld is dat van Nirvanix, waar klanten na het faillissement ingelicht werden dat de diensten over twee weken gestopt zouden worden (Butler, 2013, 20 september) (Schaffer, 2014).
3.6 Conclusie
Het antwoord op de deelvraag “Wat voor redenen zijn er om een SaaS exit te initiëren?” luidt dat er diverse redenen kunnen zijn om een SaaS contract te willen beëindigen, bijvoorbeeld op initiatief van de gebruiker van de SaaS-diensten. Maar er kan ook sprake van een gedwongen exit als gevolg van het faillissement van de leverancier. De situatie kan gedurende de afname van de SaaS-diensten wijzigen en voor de afnemer van SaaS-diensten reden zijn om de dienst te willen beëindigen. De reden van beëindiging kan invloed hebben op de omstandigheid waarbinnen een exit plaats vindt, zoals bijvoorbeeld de tijd die daarvoor beschikbaar is en zal dus invloed hebben op de toepasselijke exit strategie voor die specifieke situatie.
20
4
Risico’s
4.1 Inleiding
Dit hoofdstuk beantwoordt de deelvraag: “welke risico’s loopt de uitbestedende organisatie bij een SaaS exit?”. In de gehanteerde definitie voor exit strategieën (zie hoofdstuk 2) staat dat deze strategieën moeten worden ontwikkeld om ervoor te zorgen dat de organisatie de afgenomen dienstverlening kan beëindigen zonder andere processen binnen de organisatie te verstoren. In dit hoofdstuk wordt middels bureauonderzoek gekeken naar de risico’s van een SaaS exit. Concreet houdt dit in dat alle aan de auteur ter beschikking staande bronnen zijn verzameld en op een inductieve wijze zijn verwerkt.
Voor de bespreking van de middels het bureauonderzoek geïdentificeerde risico’s in paragraaf 4.7, wordt er eerst aandacht besteed aan voorwaardelijke aspecten voor risicoanalyse. Paragraaf 4.3 gaat in op het bepalen van het belang van de SaaS-applicatie voor de organisatie als uitgangspunt voor risicoanalyse. Paragraaf 4.4 behandelt de Risk Appetite Statement van de organisatie waaraan de geïdentificeerde risico’s getoetst worden. Paragraaf 4.5 benoemt de inherente risico’s bij het gebruik van SaaS-diensten. Paragraaf 4.6 geeft dan de kern van dit hoofdstuk weer; de resultaten van het bureauonderzoek naar risico’s bij een SaaS exit. Paragraaf 4.7 vertaalt de resultaten van dit hoofdstuk naar input voor het referentiemodel van hoofdstuk 6. Tenslotte is in paragraaf 4.8 concluderend het antwoord geformuleerd op de in dit hoofdstuk centraal staande deelvraag.
4.2 Verantwoording
De gehanteerde onderzoeksmethode in dit hoofdstuk is bureauonderzoek. Middels het bureauonderzoek is in de vakliteratuur echter geen alomvattend overzicht aangetroffen waarin alle relevante risico’s staan met betrekking tot een SaaS exit. Weliswaar geeft bijvoorbeeld ISACA (2012, p17-24, 2014a, p. 25-33 en 2014b, p. 53-61) een overzicht van de risico’s van het gebruik van cloud diensten. Deze risico’s zijn echter meer gericht op het gebruik van de verschillende Cloud modellen en niet specifiek gericht op SaaS exits.
Wel is er in de vakliteratuur, in de media en via gepubliceerde meningen van personen in het vakgebied informatie aangetroffen over doelen van een exit strategie en over vaak afzonderlijke risico’s rondom een SaaS exit. De personen zijn veelal werkzaam in het vakgebied en of bij gerenommeerde adviesbureaus en genieten daarom een zekere autoriteit. Het nadeel is dat de gevonden artikelen en meningen vaak een ander doel dienen. De beschikbare informatie is daarom verzameld, geanalyseerd en geïnterpreteerd om te komen tot de lijst met risico’s van SaaS exits zoals die in paragraaf 4.6 is weergegeven.
Als maatregel om van de geïdentificeerde risico’s kwaliteitsaspecten als juistheid en volledigheid te valideren zal de lijst met geïdentificeerde risico’s worden voorgelegd aan verschillende deskundigen in het vakgebied met elk afzonderlijke, aanvullende expertises (zie Hoofdstuk 7).
4.3 Belang applicatie(gegevens) voor risicoanalyse
Het bepalen van het belang van de SaaS-applicatie voor de organisatie is de start voor de analyse van risico’s. Van Houten, Spruit en Wolters (2015, p.128) geven aan dat het bedrijfsproces het uitgangspunt voor risicoanalyse is. Het bedrijfsproces wordt immers ondersteund door het informatiesysteem, in dit kader de SaaS-applicatie. Het belang differentiëren zij naar de betrouwbaarheidsaspecten Beschikbaarheid, Integriteit en Vertrouwelijkheid (BIV). Het is van
21
belang om te bepalen wat het belang van de SaaS-applicatie als (deel van) een informatiesysteem is waarvoor de risico’s geanalyseerd moeten worden. Het NIST (2012) heeft een uitvoerige handleiding opgesteld voor het doen van risicoanalyses.
De Nederlandsche Bank stelt eveneens dat onder toezicht staande ondernemingen een risicoanalyse moeten uitvoeren met betrekking tot de risico’s van Cloud Computing (DNB, 2011), en geeft aan waar deze risicoanalyse aan moet voldoen: “Deze risicoanalyse omvat minimaal een
beoordeling van compliance met bestaande wet- en regelgeving, de gemaakte afspraken met betrekking tot de aangeboden diensten (de overeenkomst), de stabiliteit en betrouwbaarheid van de service provider, de locatie waar de diensten worden aangeboden, en het belang en afhankelijkheid van de IT-diensten en/of IT-componenten. Voor cloud computing dient hierbij expliciete aandacht besteed te worden aan de risico’s die samenhangen met onder meer de integriteit, vertrouwelijkheid en beschikbaarheid van data. Tevens dient inzichtelijk te zijn op welke locatie de bedrijfsdata wordt bewerkt en opgeslagen. Indien de onderneming niet langer gebruik maakt van de service van de derde dient zij alle data veilig te stellen en zich ervan te vergewissen dat alle data is verwijderd van de systemen van de derde.”
Ook de European Banking Authority (EBA, 2017, p. 12) geeft aan dat de materialiteit van de te outsourcen activiteiten bepaald moet worden en het inherente risicoprofiel. Hierbij dient expliciet rekening gehouden te worden met de vraag of het activiteiten zijn die essentieel zijn voor bedrijfsprocessen en de levensvatbaarheid van de organisatie en de verplichtingen aan haar klanten. Met betrekking tot risico’s bij SaaS exits en de daarvoor op te stellen SaaS exit strategieën zal bepaald moeten worden wat het belang is van de applicatie voor de organisatie, bijvoorbeeld in termen van Beschikbaarheid, Integriteit en Vertrouwelijkheid.
4.4 Risk Appetite Statement
De Risk Appetite Statement (RAS) aan in hoeverre de organisatie bereid is risico’s te accepteren. De risk appetite wordt vastgesteld en afgestemd op de strategie van de organisatie; bedrijfsdoelstellingen vertalen de strategie naar de praktijk, terwijl ze dienen als basis voor het identificeren, beoordelen en reageren op risico's. Zoals in paragraaf 1.3.2 al aangegeven valt de totstandkoming van de Risk Appetite Statement als onderdeel van de stap ‘Strategy en Objective Setting’ (COSO, 2017) buiten de scope van dit onderzoek. Zie Bijlage 1 voor meer informatie over COSO.
Met betrekking tot risico’s bij SaaS Exits zal er een Risk Appetite Statement moeten zijn, waar mede op basis van het belang van de applicatie de geïdentificeerde risico’s kunnen worden getoetst. Dit zal input zijn voor de te nemen mitigerende maatregelen (zie hoofdstuk 5).
4.5 Inherente risico’s gebruik van SaaS-diensten
Alvorens in te gaan op de risico’s die een SaaS exit strategie beoogt te mitigeren of de risico’s die tijdens de daadwerkelijke uitvoering van exit een rol spelen, geeft deze paragraaf een globaal beeld van de inherente risico’s die het gebruik van SaaS-diensten met zich mee brengen. Aan het gebruik van diensten van de cloud zijn risico’s verbonden. SaaS-diensten brengen met zich mee dat de uitbestedende organisatie de controle over het proces in de handen van de CSP legt. Weliswaar is er indirect controle, maar dit kan onvoldoende effectief of niet tijdig genoeg zijn. Gartner (2016b) geeft immers aan dat de toegenomen afhankelijkheid van cloud diensten en het toegenomen
22
gebruik van externe dienstverleners, ervoor zorgt dat organisaties kwetsbaar zijn voor een breed scala aan onbekende single point of failures.
ISACA (2012, p17-24, 2014a, p. 25-33 en 2014b, p. 53-61) identificeert aan de hand van risico factoren per dienstverleningsmodel en implementatiemodel, een vijftal inherente risico’s die samenhangen met het gebruik van cloud computing, waarbij geldt dat IaaS en PaaS risico’s ook voor SaaS van toepassing zijn:
• Onbeschikbaarheid van de applicatie; • Diefstal van gegevens;
• Verlies van gegevens;
• Openbaarmaking van gegevens; • Kosten.
4.6 Risico’s SaaS exit
In de vorige paragraaf zijn een vijftal inherente risico’s benoemd die samenhangen met cloud computing. In deze paragraaf wordt meer invulling gegeven aan deze inherente risico’s bij een SaaS exit aan de hand van de beschikbare bronnen.
In lijn met de binnen dit onderzoek gehanteerde definitie van een exit strategie, waarbij het gaat het om het niet verstoren van andere processen binnen de organisatie, geeft de EBA (2017, art. 27) aan dat een uitbestedende instelling ervoor moet zorgen dat zij, indien nodig, uit cloud-uitbestedingsovereenkomsten moet kunnen stappen zonder onnodige verstoring van hun dienstverlening of nadelige gevolgen voor de naleving van het regelgevingsstelsel en voor de continuïteit en kwaliteit van haar dienstverlening aan klanten. Dit is te beschouwen al de minimale vereisten voor een exit strategie.
De NOA (2014, p. 7) beschrijft de daarentegen de kenmerken van een goede exit van een outsourcing, waarnaar gestreefd dient te worden in een exit strategie. Een exit is te beschouwen als ‘goed’ wanneer:
• De exit als een belangrijk succescriterium in het contract gedefinieerd is;
• Er rekening met de exit gehouden wordt en ervoor gepland wordt tijdens de relatie met de leverancier;
• Op het moment dat de exit plaats gaat vinden, dit tijdig en volledig wordt gecommuniceerd;
• De risico’s naar behoren zijn ingeschat; • De exit op tijd wordt uitgevoerd; • De exit redelijk en billijk begroot is; • De exit wordt gezien als een project; • De exit goed gemanaged is;
• De exit een goede bezetting heeft qua resources;
• De partijen als vrienden uit elkaar gaan, waardoor het ook in de toekomst weer mogelijk is om zaken te doen.
De Weerd (2016, 16 februari), advocaat bij van Houthoff Buruma, geeft tijdens een seminar bij het Platform Outsourcing Nederland aan dat bij de uitvoering van een exit bij een outsourcing de volgende doelen nagestreefd dienen te worden:
23 • Snelle transitie;
• Minimale verstoring dienstverlening volgens overeengekomen servicelevels; • Zonder dataverlies;
• Tegen redelijke kosten.
Het niet verstoren van de andere processen binnen de organisatie komt terug in alle onderdelen die De Weerd noemt, zij het dat De Weerd het verder uitwerkt. Ook de aanbeveling van de NOA voor een goede exit bij een outsourcing komen grotendeels terug in de punten die De Weerd aanvoert. De Weerd is echter wat specifieker over data(verlies) en de omstandigheden van de exit. In de volgende paragrafen is de indeling van De Weerd daarom als een ‘kapstok’ gebruikt voor de categorisering van de op basis van bureauonderzoek geïdentificeerde risico’s bij een SaaS exit, om daarmee ook tot op zekere hoogte de volledigheid van de risico’s vast te kunnen stellen. Waarbij, op basis van eigen inzicht en ten behoeve van de verhoging van de leesbaarheid, de verdeling is gemaakt van de aangetroffen risico’s over de door De Weerd geformuleerde doelen.
4.6.1.
Continuïteit
Financiële performance CSPDe performance van de CSP kan een risico vormen voor de afnemer van clouddiensten. Het betreft performance op meerdere gebieden. Zo is al eerder opgemerkt dat een (naderend) faillissement van een leverancier grote impact kan hebben en een mogelijke directe bedreiging is voor de continuïteit van de diensten.
Strategiewijziging en operationele performance CSP
Ook een wijziging in de strategie van de CSP kan invloed hebben op de (ontwikkeling van) de producten die de CSP voert. SaaS-applicaties kunnen gestopt worden of er kan een verminderde focus zijn op het beheer en de verdere ontwikkeling. Verstoring van de continuïteit van het bedrijfsproces is dan een potentieel risico. Giarte (2016, p27) stelt zelfs dat het de ultieme nachtmerrie is voor een CIO dat een clouddienst ‘verdwijnt’.
4.6.2.
Snelle transitie
Inadequaat begrip exitBij een exit van een SaaS-applicatie ken het voorkomen dat er onvoldoende begrip is van wat er bij een dergelijke exit komt kijken. Het NOA (2014, p2) beschrijft de risico’s van een inadequaat begrip van:
• het exit proces en
• de tijd die benodigd is voor het uitvoeren van een exit en
• de kosten die gemoeid zijn met een exit en daarmee van de business case die ten grondslag ligt aan de keuze om een exit te initiëren.
Ontbreken vooropgesteld plan
Ook Engelfriet, A. & Ras, S. (2015, pp. 168-169) geven aan dat bij ICT-contracten niet altijd duidelijk is wat er moet gebeuren na een opzegging. Bij SaaS-diensten en hosting kan opzegging tot gevolg hebben dat de leverancier accounts opheft en opgeslagen data wist. Dit kan desastreuze gevolgen hebben voor de organisatie voor de hierboven gedefinieerde, te realiseren doelen van de exit.
24 Beschikbare tijd voor exit scenario
Zoals reeds in hoofdstuk 3 geconstateerd is de beschikbare tijd om een exit scenario uit te voeren een belangrijk aspect van een exit. Bruno (2013) geeft eveneens aan dat de tijd die benodigd is om de SaaS-dienst te vervangen een risico is: doorlooptijd is nodig voor een ordentelijke, beheerste exit. De tijd die beschikbaar is als gevolg van bijvoorbeeld een faillissement kan echter beperkt zijn om dit op de juiste manier uit te voeren. Daarbij speelt ook de vraag of er alternatieven direct beschikbaar en bruikbaar zijn.
4.6.3.
Minimale verstoring diensten conform servicelevels
Houding CSP bij exitHet NIST (2003, p. 41) geeft aan dat CSP’s niet altijd de beste intenties hebben voor vertrekkende afnemers en zullen het voor hen niet makkelijk maken om naar een andere partij te gaan. Giarte (2015, p. 13) geeft meer specifiek aan dat het voorkomt dat de houding van de latende partij zeer formeel wordt, vooral op het gebied van communicatie. Dit is met name een probleem als er weinig gedocumenteerd is en veel kennis impliciet bij de medewerkers van de latende partij zit. Dit zorgt voor het risico van vertraging van het exit project of kan het zelfs voorkomen dat het tot stilstand komt. Ook kan het zijn dat voor iedere overdrachtsactiviteit door een aanvraag voorafgegaan moet worden, waarna er een offerte wordt opgesteld.
4.6.4.
Zonder dataverlies
Data extractieVeel bedrijven komen na de overgang naar de cloud er volgens Gartner (2016a) pas achter dat het bijna onmogelijk is om hun data weer terug te krijgen. Vijf voorname uitdagingen zijn daarbij:
1. Bandbreedte en kosten voor data extractie (zie ook paragraaf 4.5.4) 2. Het mechanisme en het formaat van de data
3. Tijdverslindende data conversie
4. Het eigendom van de data en de metadata, taxonomie of folder structuren
5. De benodigde interne skills zijn minder of niet (meer) aanwezig in het bedrijf om de data te migreren.
ISACA (2014a, p29) geeft aan, in aanvulling op punt 2, de overdracht van data als een risico te zien: "Momenteel is er erg weinig beschikbaar in termen van tools, procedures of andere diensten om gegevens- of service portabiliteit van CSP naar CSP te vergemakkelijken. Dit kan het voor de onderneming erg moeilijk maken om van de ene CSP naar de andere te migreren of om diensten naar binnen te halen. Het kan ook leiden tot ernstige verstoringen als de CSP failliet gaat, juridische stappen onderneemt of het potentiële doelwit is voor een acquisitie (met de kans op plotselinge wijzigingen in het CSP-beleid en eventuele bestaande overeenkomsten). Als de klant-CSP-relatie slecht wordt en de onderneming de gegevens terug wil halen, wordt de vraag van kritiek belang hoe de gegevens veilig kunnen worden weergegeven, omdat de interne applicaties zijn ontmanteld of "sunsetted" en er geen toepassing beschikbaar is om de gegevens weer te geven. "
Veldhuis (2015, 3 juni) geeft eveneens in aanvulling op punt 2 aan en dat er geen standaardformaat voor data uitwisseling (zoals bijvoorbeeld API’s) is voor SaaS-diensten en dat de uitwisselbaarheid daardoor nihil is.
Ter verduidelijking van punt 4 wijst De Jongh in Automatiseringsgids Connect (2014, 9 januari) erop van de SaaS-provider een expliciete erkenning te vragen van het principe dat de data van de opdrachtgever is en blijft. “De meeste SaaS-leveranciers hebben geen juridische en financiële
25
maatregelen getroffen om te voorkomen dat de SaaS-infrastructuur – met daarop klantenbestanden en -data – bij een eventueel faillissement als onderdeel van de totale boedel eigendom wordt van de [door de curator vertegenwoordigde] schuldeisers”.
‘Run on the banks’ scenario
In aanvulling op de vorige paragraaf is er het zogenaamde ‘Run on the banks’ scenario. ISACA (2014a, p87) beschrijft het risico van een ‘run on the banks’ scenario als de CSP bijvoorbeeld failliet gaat. Heiser van Gartner (2013, September 13) beschrijft de relevante aspecten: “Wat voor een
data-storm krijg je als duizenden klanten tegelijkertijd proberen om petabytes aan data te kopiëren? Hoeveel technische ondersteuning kan een bedrijf bieden als ze failliet gaat? Kun je redelijkerwijs verwachten dat hun personeel gemotiveerd zal blijven om aan te blijven en alle noodzakelijke, heldhaftige inspanningen te ondernemen die nodig zijn om je te helpen bij het herstellen van je gegevens? Waar ga je die gegevens plaatsen?”
Het moge duidelijk zijn dat in een dergelijk scenario de afgesproken servicelevels zeer waarschijnlijk niet nageleefd zullen (kunnen) worden. Ook voor minder extreme scenario’s is het, op basis van de definitie van een exit strategie gewenst, dat de andere processen van de organisatie niet verstoord worden en de SaaS-applicatie blijft werken conform de afgesproken servicelevels.
Data verwijdering na exit
De Automatiseringsgids (2016, 2 februari) wijst er qua ‘dataverlies’ op dat de afnemer van een SaaS-dienst er zeker van wil zijn dat gegevens verwijderd worden, om diefstal of openbaarmaking van gegevens te voorkomen.
4.6.5.
Tegen redelijke kosten
Afspraken over kosten exitIn aanvulling op het in de vorige paragraaf genoemde aspect van kosten van de datamigratie zelf, blijkt volgens de Automatiseringsgids (2016, 1 februari) dat wanneer er vooraf geen afspraken over een exit gemaakt zijn, plotseling kan blijken dat er enorme tarieven gerekend worden voor medewerking aan datamigratie, verwijdering van data, consultancy et cetera. Verder blijkt vaak ook dat de oorspronkelijke medewerkers van het project gehaald worden, waardoor er minder value for money is.
Total Cost of Ownership
Bruno (2013) geeft aan dat bij het verkennen van het vervangen van een SaaS-dienst er verder gekeken moet worden dan alleen de abonnementskosten, omdat dat alleen maar een percentage van de TCO (Total Cost of Ownership) is. Dit zou ertoe kunnen leiden dat er een keuze gemaakt wordt om een exit uit te voeren die later tegenvalt in verband met de (onverwacht) hogere totale kosten.
4.6.6.
Aanvullende risico’s
Aanvullende risico’s die specifiek terugkomen in relatie tot SaaS zijn de ‘vendor lock in’, de ‘ease of contracting’ het voldoen aan wet- en regelgeving. Zie hieronder voor de beschrijving van deze risico’s.
Vendor lock-in
Veel van de in dit hoofdstuk geïdentificeerde risico’s kunnen op zichzelf of bij gelijktijdig optreden voor een vendor lock-in zorgen. De Automatiseringsgids (2017, 9 augustus) geeft aan dat vendor lock-in een probleem wordt in de cloud. Het risico is voor de afnemer van de SaaS-dienst is dat hij
26
in feite te maken krijgt met het ‘Hotel California’-effect: Je kunt wel wegwillen bij een CSP, maar je komt er nooit weg…
Ease of contracting: ongunstige en onvolledige contracten
ISACA (2014, p. 59-60) beschouwt het gemak waarmee er gecontracteerd kan worden als een van de specifieke risico’s van SaaS. Het is een algemene ontwikkeling (Huijbers, 2017, 7 september) dat SaaS meer buiten de CIO om gebruikt en gecontracteerd wordt, dit levert risico’s op meerdere gebieden op. De kans is dan groot dat door minder bewustzijn en of kennis de business geen maatregelen overeenkomt met de CSP voor beëindiging of bijvoorbeeld een exit plan.
Voldoen aan wet- en regelgeving
Zoals eerder opgemerkt in paragraaf 1.1 met betrekking tot DNB, geeft ook de EBA (2017, art. 27) aan dat een uitbestedende instelling ervoor moet zorgen dat zij, indien nodig, bijvoorbeeld bij wijzigingen in wet- en regelgeving, uit cloud-uitbestedingsovereenkomsten moet kunnen stappen onder meer zonder nadelige gevolgen voor de naleving van het regelgevingsstelsel. Hoewel dit wellicht specifiek geldt voor onder toezicht staande instellingen, kan meer generiek gesteld worden dat het niet meer kunnen voldoen aan wet- en regelgeving eveneens gezien kan worden als een risico.
4.7 Risico’s in het referentiemodel
Samenvattend kan gesteld worden dat er in het onderzoek voorbeelden zijn aangetroffen gerelateerd aan de doelen van die betrekking hebben op SaaS exits:
1. Financiële performance CSP; 2. Operationele performance CSP;
3. Strategiewijziging CSP, waardoor minder focus op SaaS-applicatie; 4. Inadequaat begrip exit;
5. Ontbreken vooropgesteld plan; 6. Beschikbare tijd voor exit scenario; 7. Houding CSP bij exit;
8. Data extractie: Bandbreedte en kosten voor data extractie; 9. Data extractie: Het mechanisme en het formaat van de data; 10. Data extractie: Tijdverslindende data conversie;
11. Data extractie: Het eigendom van de data en de metadata, taxonomie of folder structuren;
12. Data extractie: De benodigde interne skills zijn minder of niet (meer) aanwezig in het bedrijf om de data te migreren;
13. Data extractie: ‘Run on the banks’ scenario; te weinig tijd en bandbreedte om de data te extraheren;
14. Data extractie: Data verwijdering na exit; 15. Afspraken over kosten exit;
16. Total Cost of Ownership; 17. Vendor lock-in;
18. Ease of contracting: ongunstige en onvolledige contracten; 19. Voldoen aan wet- en regelgeving.
Om de kwaliteit te toetsen en eventuele lacunes aan te vullen, zal in hoofdstuk 7 middels de casestudy bovenstaande meegenomen bij de toetsing door experts met betrekking tot deze materie.
27
4.8 Conclusie
Het antwoord op de deelvraag “Welke risico’s loopt de uitbestedende organisatie bij een SaaS exit?” wordt in deze paragraaf op basis van het verrichte onderzoek gegeven. De uitbestedende organisatie loopt bij een SaaS exit risico’s die betrekking hebben op: continuïteit, doorlooptijd, verstoring en of verslechtering van de dienstverlening, dataverlies en kosten. In het hoofdstuk is meer inhoud gegeven aan deze risico’s en zijn ook de risico’s vendor lock in en ease of contracting geïdentificeerd. Daarnaast is naar voren gekomen dat, voorafgaand aan de risicoanalyse van de SaaS exit, het belang van de SaaS-applicatie moet zijn bepaald en dat de risk appetite statement de basis vormt voor de identificatie beoordelen en het reageren op risico’s.
28
5
Mitigerende maatregelen
5.1 Inleiding
In dit hoofdstuk wordt antwoord gegeven op de deelvraag: ‘Wat zijn potentiële maatregelen binnen een SaaS exit strategie?’ De doelen en risico’s die geïdentificeerd zijn in het vorige hoofdstuk zullen hierbij zoveel mogelijk als uitgangspunt dienen. Aan de hand van bureauonderzoek is gezocht naar mitigerende maatregelen bij SaaS exits. Als indeling is in beginsel de indeling in doelen en risico’s aangehouden zoals in het vorige hoofdstuk. Het is overigens mogelijk dat een mitigerende maatregel meerdere risico’s mitigeert, dit zal verder worden onderzocht in hoofdstuk 6.
5.2 Verantwoording
De gehanteerde onderzoeksmethode is ook in dit hoofdstuk bureauonderzoek. Bureauonderzoek maakt mogelijk dat in betrekkelijk korte tijd een veelheid aan informatie kan worden verzameld, zoals ook in dit hoofdstuk is gebeurd. De gevonden informatie heeft vaak een ander doel dan de mitigerende maatregelen bij een SaaS exit weer te geven. Dit betekent dat gegevens zijn verzameld, geanalyseerd en er interpretaties zijn gemaakt om tot de maatregelen te komen zoals in dit hoofdstuk weergegeven. Gebruik gemaakt is van (voor zover aanwezige) vakliteratuur, in de media en op het internet gepubliceerde meningen van personen in het vakgebied. Vaak gaat de gevonden informatie over afzonderlijke risico’s rondom een SaaS exit en de mitigerende maatregelen die daarbij genomen kunnen worden.
De personen zijn veelal werkzaam in het vakgebied en of bij gerenommeerde adviesbureaus en genieten daarom een zekere autoriteit. Waar mogelijk is gebruik gemaakt van triangulatie om de relevantie van een mitigerende maatregel te onderstrepen. Dit alles heeft geleid tot de overtuiging dat de in de beschikbare bronnen vindbare informatie is verzameld.
Als aanvullende maatregel om van de geïdentificeerde mitigerende maatregelen kwaliteitsaspecten als juistheid en volledigheid te valideren zal de lijst met geïdentificeerde mitigerende maatregelen worden voorgelegd aan verschillende deskundigen in het vakgebied met elk afzonderlijke, aanvullende expertises (zie Hoofdstuk 7). Met deze maatregel wordt er ook naar gestreefd om mitigerende maatregelen te identificeren die wellicht nog niet beschreven zijn in de beschikbare bronnen.
5.3 Mitigerende maatregelen per risico
5.2.1.
Continuïteit
Financiële performance CSP
Om een (dreigend) faillissement van een CSP voor te zijn, is het raadzaam (Bruno, 2013) voor contractering een aantal vragen te stellen: Hoeveel jaar bestaat de CSP al? Hoeveel medewerkers binnen de CSP kennen de technologie van de SaaS-applicatie? Een en ander om meer inzicht te krijgen in de betrouwbaarheid van de leverancier. Een periodieke evaluatie van de leverancier en eventuele toeleveranciers is een maatregel om een faillissement voor te zijn.
Operationele performance CSP
Naast de financiële performance is er ook de operationele performance. De EBA (2017, art. 28a) beveelt aan om key risk indicators te ontwikkelen die een onacceptabel serviceniveau moeten
29
identificeren. Het onder het acceptabele serviceniveau komen van de key risk indicators kan dan een trigger zijn om het exit plan in werking te stellen. De EBA geeft dan ook aan dat deze indicatoren moeten worden gemonitord om het exit plan te kunnen activeren als onderdeel van de doorlopende monitoring van en het toezicht op de diensten van de CSP.
Strategiewijziging CSP
Om tijdig in te kunnen spelen op een veranderende focus in de strategie van de CSP is het van belang (Bruno, 2013) om vooraf en tijdens het gebruik van een SaaS-dienst vragen te stellen als: “Hoe lang bestaat de specifieke SaaS-dient al?” en “Is de cloud dient aan de eind van de ‘hype cycle’?”. Dit teneinde tijdig de situatie in te kunnen schatten dat er onvoldoende effort wordt gestoken in verdere ontwikkeling van de SaaS-dienst en maatregelen te kunnen nemen, zoals bijvoorbeeld het tijdig overstappen naar een andere CSP.
5.2.2.
Snelle transitie
Inadequaat begrip exitZoals vermeld in paragraaf 1.3.1 wordt erkend dat een exit strategie van belang is. Hoe deze exit strategie eruitziet, welke scenario’s en welke mitigerende maatregelen daar onderdeel van uitmaken, hangt van de specifieke situatie af. Het management moet zich bewust zijn van de geformuleerde exit strategieën en bereid zijn die snel uit te voeren. Gartner (2016b) geeft aan dat een organisatie meerdere exit strategieën voorbereid moet hebben die klaar zijn voor uitvoering. Ook het NIST (2011 p. 42) geeft aan dat een organisatie meerdere exit strategieën voorbereid moet hebben en er klaar voor moet zijn om deze, zo nodig snel, te implementeren. Doets (2016, 8 januari) geeft aan dat elke te definiëren strategie altijd maatwerk is, afhankelijk van de afgenomen clouddienst.
Ontbreken vooropgesteld plan
Het ontbreken van een vooropgesteld exit plan kan ervoor zorgen dat een exit (te) lang gaat duren, doordat onduidelijk is wie precies wat moet gaan doen. Cohen en Young (2006, p. 169) geven aan dat een exit plan moet aangeven welke acties benodigd zijn van de serviceprovider tijdens de exit. Daarin inbegrepen zijn de proces documentatie, toegang tot historische data en databases, key personeel (beschreven per rol) dat ingehuurd kan worden en de kennisoverdracht.
Giarte (2015, p. 15) beschrijft de volgende aandachtspunten voor het exit plan met de leverancier: 1. Afspraken dat de latende leverancier relevante kennis en middelen beschikbaar houdt, en
dat zij zich committeert aan het leveren van een ervaren projectmanager met vergelijkbare ervaring.
2. Maak een lijst van key (sleutel) personeel bij de leverancier, dat niet vervangen mag worden vanaf het moment van aanzegging van het einde van het contract.
3. Voorkom dat de leverancier personeel vervangt door minder competente of minder ervaren krachten
4. Maak afspraken over open communicatie tussen de nieuwe en de latende leverancier. Ad 2 en 3. geeft Doets (2016, 8 januari) aan dat vooraf aan de daadwerkelijke exit geregeld moet zijn wie er bij een exit betrokken zijn (projectorganisatie, verantwoordelijkheden, namen, telefoonnummers, rechten en plichten).
DNB (2011) geeft aan dat voor onder toezicht staande instellingen in de overeenkomst met de CSP geregeld moet zijn: de wijze waarop de overeenkomst wordt beëindigd, en de wijze waarop wordt
