10.08.2015 Views

20080325 - 801 - Scriptie - definitief - Vurore

20080325 - 801 - Scriptie - definitief - Vurore

20080325 - 801 - Scriptie - definitief - Vurore

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

InhoudsopgaveColofon ________________________________________________________________________ 2Voorwoord _____________________________________________________________________ 3Samenvatting __________________________________________________________________ 41 Inleiding en onderzoeksopzet__________________________________________________ 61.1 Inleiding __________________________________________________________________________ 61.2 Aanleiding voor het onderzoek ____________________________________________________ 62 Theoretisch kader SLA’s en beveiliging in een overheidsomgeving______________ 112.1 Inleiding _________________________________________________________________________ 112.2 Relatie tussen de gebruikersorganisatie en IT-serviceorganisatie _____________________ 112.2.1 Kenmerken/typering van de gebruikersorganisatie 122.2.2 Kenmerken/typering van de IT-serviceorganisatie 132.2.3 Verschillen tussen de gebruikers- en IT-serviceorganisatie 132.3 Wat is de definitie van een Service Level Agreement? ______________________________ 132.4 Welke soorten Service Level Agreements zijn te onderkennen?______________________ 142.5 Wat is het doel van het opstellen van een Service Level Agreement? _______________ 162.6 Hoe komt een Service Level Agreement idealiter tot stand? ________________________ 162.7 Wat houdt beveiliging in vanuit IV-dienstverleningsperspectief? _____________________ 183 Uitkomsten praktijkonderzoek ________________________________________________ 203.1 Inleiding _________________________________________________________________________ 203.2 Algemeen _______________________________________________________________________ 203.3 Lifecycle van een SLA ____________________________________________________________ 213.4 Inhoud van een SLA (algemeen) __________________________________________________ 233.5 Inhoud van een SLA (beveiliging) _________________________________________________ 244 Het auditinstrument __________________________________________________________ 254.1 Inleiding _________________________________________________________________________ 254.2 Het instrument ___________________________________________________________________ 255 Conclusies en aanbevelingen ________________________________________________ 286 Reflectie_____________________________________________________________________ 29Literatuurlijst ___________________________________________________________________ 30Bijlagen _______________________________________________________________________ 31Bijlage 1 - aspecten van een SLA _____________________________________________________ 31Bijlage 2 - VIR 2007, Code voor Informatiebeveiliging, Cobit en ITIL______________________ 37Bijlage 3 - gehanteerde gestructureerde vragenlijst ____________________________________ 42Bijlage 4 - het Auditinstrument ________________________________________________________ 45Afstudeerscriptie team <strong>801</strong> blz. 5 van 49


1 Inleiding en onderzoeksopzet1.1 InleidingDit hoofdstuk gaat in op de aanleiding voor het onderzoek en deonderzoeksaanpak.Allereerst is in paragraaf 1.1 de aanleiding voor dit afstudeeronderzoek beschreven.Paragraaf 1.2 gaat in op de centrale vraagstelling en de bijbehorende deelvragen.Vervolgens wordt de onderzoeksaanpak in paragraaf 1.3 beschreven. Paragraaf 1.4beschrijft het resultaat van het onderzoek en tot slot wordt in paragraaf 1.5 deindeling van deze scriptie toegelicht.1.2 Aanleiding voor het onderzoekIn de afgelopen decennia is er toenemende aandacht voor de beschikbaarheid enhet verstrekken van informatie. Dit uit zich ook in de toenemende communicatietussen enerzijds de Rijksoverheid en anderzijds de burgers en het bedrijfsleven. Deintegriteit van informatie moet hierbij voldoende geborgd zijn. Daarnaast is het vanbelang dat geen verkeerde informatie wordt uitgewisseld en dat wordt voorkomendat informatie terechtkomt bij niet geautoriseerde personen. De consequentiehiervan is dat meer aandacht wordt besteed aan de informatiebeveiliging.De informatievoorziening - het geheel van mensen, middelen en maatregelen,gericht op de informatiebehoefte van een organisatie - steunt voor een groot deelop IT. Binnen de Rijksoverheid vormt IT geen ‘core business’ en wordt daarom vaakuitbesteed aan daartoe gespecialiseerde dienstverleners. Daarbij stelt deRijksoverheid kwaliteitseisen aan die uitbestede dienstverlening.Vanuit het perspectief van IV-dienstverlening - het totaal van ontwikkeling,onderhoud, beheer en exploitatie van de IV-infrastructuur - wordt onderscheidgemaakt tussen een gebruikersorganisatie en een IT-serviceorganisatie.Onder IT-serviceorganisatie wordt de eerder genoemde gespecialiseerdedienstverlener bedoeld.De gebruikersorganisatie en de IT-serviceorganisatie stemmen vraag en aanbod afen maken vervolgens afspraken over de te leveren diensten door de IT-serviceorganisatie.Een Service Level Agreement is een middel om deze afspraken vast teleggen.Afstudeerscriptie team <strong>801</strong> blz. 6 van 49


De relatie tussen de gebruikersorganisatie en de IT-serviceorganisatie wordt als volgtgevisualiseerd:Gebruikersorganisatie IT-serviceorganisatie ExterneleverancierKadersRandvoorwaardenWederzijdseafstemmingUnderpinningcontract(UC)Leverancier:A …B …C …DienstenOperationalLevelAgreement(OLA)BehoeftenFiguur 1: relatie tussen gebruikersorganisatie en IT-serviceorganisatie(Bron: figuur is afgeleid van de presentatie “trappetjesmodel als opstap naar eendienstverleningsmodel” van Dr. P.H.A.M. Frijns, Apeldoorn, sept. 2007)1.3 OnderzoeksvragenDe doelstelling van deze scriptie 1 is het ontwerpen van een instrument dat gebruiktkan worden binnen de Rijksoverheid bij de totstandkoming van een SLA of bij debeoordeling van een gerealiseerde SLA, waarbij het onderwerpinformatiebeveiliging voldoende wordt belicht. Het instrument kan door de ITauditor,maar ook door een adviseur gebruikt worden die wordt gevraagd hetproces van totstandkomen van een SLA te begeleiden.Uit deze doelstelling is de volgende centrale onderzoeksvraag afgeleid:Centrale onderzoeksvraag:Op welke wijze kan worden getoetst of aan de eisen wordt voldaan die aan eenService Level Agreement (SLA) worden gesteld, om de afstemming tussen degebruikersorganisatie en de IT-serviceorganisatie binnen de Rijksoverheid vast teleggen, waarbij ook de noodzakelijke informatiebeveiliging in opzet, bestaan enwerking in de IV-dienstverleningsketen is geborgd?De belangrijkste elementen uit de centrale onderzoeksvraag 2 zijn onderstreept. Omde centrale onderzoeksvraag te kunnen beantwoorden zijn de volgendedeelvragen geformuleerd en gegroepeerd naar bovengenoemde elementen:1 J.H.J. v/d Heuvel - Hoe schrijf ik een scriptie of these? (2004)2 U. Eco - Hoe schrijf ik een scriptie? (2005)Afstudeerscriptie team <strong>801</strong> blz. 7 van 49


Deelvragen:Gebruikersorganisatie en IT-serviceorganisatie1. Wat wordt verstaan onder gebruikersorganisatie?2. Wat wordt verstaan onder een IT-serviceorganisatie?3. Welke verschillen zijn te onderkennen tussen gebruikers- en IT-serviceorganisatie?Service Level Agreement4. Wat is de definitie van een Service Level Agreement?5. Welke soorten Service Level Agreements zijn te onderkennen?6. Wat is het doel van het opstellen van een Service Level Agreement?7. Hoe komt een Service Level Agreement idealiter tot stand?Informatiebeveiliging8. Wat houdt beveiliging in vanuit IV-dienstverleningsperspectief?Auditinstrument9. Waaraan moet een Service Level Agreement voldoen?10. Waaraan moet het proces van totstandkoming en gebruik van een Service LevelAgreement voldoen?11. Hoe kan getoetst worden of in de Service Level Agreement de essentiëleonderwerpen zijn benoemd?1.4 Resultaat van het onderzoekHet resultaat van het onderzoek is een auditinstrument waarin de te stellen eisen aaneen SLA en de totstandkoming daarvan zijn opgenomen. Het gaat om eenalgemeen instrument met eisen/vragen die door de organisaties kunnen wordengesteld om op een goede wijze invulling te geven aan de samenwerking. Dezeeisen/vragen dragen bij aan het optimaliseren van de afstemming tussen degebruikersorganisatie en IT-serviceorganisatie. Dit instrument is zowel toepasbaarvoor de auditor als voor de adviseur die gevraagd wordt het totstandkomingsprocesvan een SLA te begeleiden.1.5 OnderzoeksaanpakFaseringDe onderzoeksaanpak bestaat uit de volgende stappen: Literatuuronderzoek; Voorbereiding praktijkonderzoek; Uitvoeren van praktijkonderzoek; Analyseren van de bevindingen; Ontwikkelen van een auditinstrument; Het trekken van conclusies en het doen van aanbevelingen.Afstudeerscriptie team <strong>801</strong> blz. 8 van 49


OnderzoeksmethodenDe methode van onderzoek 3 valt uiteen in twee delen, te weten: ‘deskresearch’ en‘praktijkonderzoek’.‘Deskresearch’Deskresearch is uitgevoerd om een beeld te krijgen van het onderzoeksterrein endefinities van begrippen. Het literatuuronderzoek is uitgevoerd om hettotstandkomingsproces van een SLA te kunnen begrijpen en de antwoorden tekrijgen op de deelvragen 1 tot en met 8. Hierbij is onder andere gebruik gemaaktvan boeken, (vak)literatuur en internet. Het resultaat van de uitgevoerdedeskresearch is opgenomen in hoofdstuk 2.PraktijkonderzoekNa de literatuurstudie is gestart met het voorbereiden van het praktijkonderzoek.Daarbij is gebruik gemaakt van de aanwezige kennis bij één ministerie.Een casus is beschikbaar gesteld voor het onderzoek. Deze casus is in de scriptie nietmet naam en toenaam genoemd om redenen van privacy.Het praktijkonderzoek is uitgevoerd door het verzamelen van relevantedocumentatie ten aanzien van de casus en het houden van interviews bij debetrokken gebruikersorganisatie en twee IT-serviceorganisaties. Het doel van deinterviews is: Vaststellen of er naast de elementen genoemd in de literatuur nog elementenvanuit de praktijk naar voren komen die relevant zijn voor het onderzoek; Nagaan of de bestudeerde literatuur toegepast is in de gehanteerde casus; Beantwoorden van de deelvragen.Aanpak interviewsOp basis van de bestudeerde theorie is een gestructureerde vragenlijst opgesteld.Deze bestaat uit de volgende onderwerpen: algemeen, totstandkoming SLA,procesrollen, inhoud algemeen en inhoud beveiliging. Het bevat alleen openvragen die niet van tevoren naar de te interviewen personen zijn gestuurd. De duurvan de gesprekken is ca.1,5 uur geweest en ze zijn uitgewerkt in een gespreksverslag.Ten behoeve van het onderzoek is een aantal medewerkers geïnterviewd.Het gaat om de volgende functionarissen: Service Level Managers,Beveiligingsambtenaar, Hoofd IT-projecten, medewerker Portfolio Management eneen Algemeen Projectmanager.De uitwerking is in alle gevallen teruggekoppeld naar de geïnterviewde terbecommentariëring. De definitieve versies zijn gebruikt in het onderzoek.ResultaatDe definitieve interviewverslagen en het theoretische kader zijn geanalyseerd. Deresultaten hiervan zijn weergegeven in hoofdstuk 3 en 4.3 D.B. van Baarda c.s. - Basisboek Methoden en Technieken (2002)Afstudeerscriptie team <strong>801</strong> blz. 9 van 49


1.6 Leeswijzer scriptieDe opbouw van deze scriptie is in onderstaande figuur weergegeven:TheorieH2 Theoretisch kader SLA’sen beveiliging in eenoverheidsomgevingPraktijkH3 BevindingenpraktijkonderzoekH4 AuditinstrumentH5 Conclusies enaanbevelingenH6 ReflectieFiguur 2: opbouw scriptieIn hoofdstuk 2 wordt ingegaan op de theorie ten aanzien van de elementen uit decentrale onderzoeksvraag: de SLA, de gebruikers- en IT-serviceorganisatie eninformatiebeveiliging.Hoofdstuk 3 geeft de resultaten van de gestructureerde interviews; daarbij wordteen aantal conclusies getrokken.In hoofdstuk 4 wordt het instrument beschreven dat is voortgekomen uit debevindingen van hoofdstuk 2 en 3. Een overzicht met de daaruit voortgekomenelementen van een SLA die voor een auditor of adviseur van belang zijn, isopgenomen.De conclusie en aanbevelingen ten aanzien van de centrale onderzoeksvraag zijnuitgewerkt in hoofdstuk 5.Hoofdstuk 6 geeft een kort exposé van onze eigen bevindingen gedurende hetonderzoek.Afstudeerscriptie team <strong>801</strong> blz. 10 van 49


2 Theoretisch kader SLA’s en beveiliging in een overheidsomgeving2.1 InleidingDit theoretische hoofdstuk is gebaseerd op de elementen uit de centraleonderzoeksvraag waarbij de volgende deelvragen zijn gesteld:1) Wat wordt verstaan onder gebruikersorganisatie?2) Wat wordt verstaan onder een IT-serviceorganisatie?3) Welke verschillen zijn te onderkennen tussen gebruikers- en IT-serviceorganisatie?4) Wat is de definitie van een Service Level Agreement?5) Welke soorten Service Level Agreements zijn te onderkennen?6) Wat is het doel van het opstellen van een Service Level Agreement?7) Hoe komt een Service Level Agreement idealiter tot stand?8) Wat houdt beveiliging in vanuit IV-dienstverleningsperspectief?2.2 Relatie tussen de gebruikersorganisatie en IT-serviceorganisatieDe laatste jaren is een sterke toename te zien van uitbesteding van IT. Een belangrijkargument daarvoor is dat gebruikersorganisaties zich willen richten op dekernactiviteiten en geen hinder willen hebben van allerlei IT-vraagstukken: het moet“gewoon” de bedrijfsvoering ondersteunen. Hierdoor wordt de behoefte vergrootom het beheer van de IT-infrastructuur, of het beheer van applicaties, uit tebesteden.Bij uitbesteding is het belangrijk dat grenzen duidelijk worden vastgelegd: deaansturing van de uitbestede IT-activiteiten en de bepaling van de gewensteinformatievoorziening in de organisatie moet bij de gebruikersorganisatie zelf wordenbelegd. Een organisatie dient zelf aan het roer te staan en wil niet door anderenlaten bepalen wat men wel en niet moet doen als het gaat om de eigeninformatievoorziening. Functioneel beheer vervult als intermediair tussen IT en deorganisatie deze rol.Tussen de gebruikersorganisatie en de IT-serviceorganisatie bestaan echterverschillen - deze worden verderop in deze paragraaf uitgewerkt - die het makenvan duidelijke afspraken over de te leveren diensten bemoeilijken.De delta tussen deze organisaties kan worden overbrugd door wederzijdseafstemming. Deze afstemming kan worden geëffectueerd op drie niveaus:Het hoogste niveau is dat van het contract tussen beide organisaties.Aansprakelijkheid en juridische aspecten worden hierin geregeld;Het middelste niveau is dat van de Service Level Agreements (SLA): op welk(kwaliteits)niveau moeten de diensten worden geleverd;Het derde niveau is dat van de Documenten, Afspraken en Procedures (DAP’s).Op operationeel niveau worden de gemaakte afspraken concreet vertaald envastgelegd.Afstudeerscriptie team <strong>801</strong> blz. 11 van 49


Figuur 1, opgenomen in hoofdstuk 1, is verder uitgewerkt en het resultaat hiervan isweergegeven in het onderstaande figuur:Gebruikersorganisatie IT-serviceorganisatie ExterneleverancierKadersRandvoorwaardenContractSLAUnderpinningcontract(UC)Leverancier:A …B …C …DAPDienstenOperationalLevelAgreement(OLA)BehoeftenFiguur 2: wederzijdse afstemming gebruikersorganisatie en IT-serviceorganisatie2.2.1 Kenmerken/typering van de gebruikersorganisatieDe gebruikersorganisatie is de organisatie die verantwoordelijk is voor de uitvoeringvan de bedrijfsprocessen die door de informatievoorziening worden ondersteund.Deze organisatie betreft zowel de eindgebruikers van een informatiesysteem als hetmiddel- en het hogere management binnen deze organisatie. Een veelgebruiktsynoniem voor gebruikersorganisatie is ‘business’ en in de terminologie van de SLA:klant of afnemer van de diensten. De gebruikersorganisatie richt zich op hetuitvoeren van activiteiten met als doel het verwezenlijken van debedrijfsdoelstellingen en -functies van de organisatie.Een adequate beschrijving van de wijze waarop een gebruikersorganisatie er voorkan zorgen dat de informatievoorziening goed werkt is bijvoorbeeld opgenomen inhet zgn. ‘Business Information Service Library (BISL)-framework’ 4 . Daar wordt ookaangegeven hoe behoeften vanuit het bedrijfsproces worden vertaald naar IToplossingenen hoe er wordt gestuurd op de informatievoorziening. Daar waar ITILzicht richt op de IT-serviceorganisatie, ‘focused’ het BISL zich op degebruikersorganisatie.Het ‘framework’ wordt ondersteund door ‘best-practices’ die betrekking hebben opfunctioneel beheer en informatiemanagement.4 BISL Business Information Services Library, June 2007Afstudeerscriptie team <strong>801</strong> blz. 12 van 49


2.2.2 Kenmerken/typering van de IT-serviceorganisatieDe IT-serviceorganisatie (of leverancier) levert alle diensten op het gebied vantechnisch beheer en applicatiebeheer die nodig zijn om invulling te geven aan devoor de gebruikersorganisatie benodigde informatievoorziening. De ITserviceorganisatiekan bij de levering van de IT-diensten gebruik maken van externeleveranciers. Deze externe leveranciers zullen opereren ten behoeve van meerdereopdrachtgevers en zijn dus actief in meerdere IT-serviceorganisaties (zie figuur 1).De IT-Serviceorganisatie is technisch georiënteerd en concentreert zich op hetleveren van technische IT diensten die gericht zijn op de ondersteuning van debedrijfsprocessen van een gebruikersorganisatie.De tegenhanger van BISL bij de gebruikersorganisatie is de ‘Information TechnologyInfrastructure Library (ITIL)’ 5 bij de IT-serviceorganisatie. Het is een referentiekadervoor het inrichten van beheerprocessen binnen een IT-organisatie. Het is geenmethode of model maar een set ‘best-practices’.2.2.3 Verschillen tussen de gebruikers- en IT-serviceorganisatieZoals in paragraaf 2.2.1 en 2.2.2 is beschreven bestaan er verschillen tussen degebruikers- en IT-serviceorganisatie. Doelstellingen, belangen en werkwijzenverschillen onderling en kunnen conflicteren. Daarom is het met name voor eengebruikersorganisatie noodzakelijk dat afspraken tussen gebruikers- en ITserviceorganisatiesworden gemaakt. Er moeten in ieder geval over de volgendetwee onderwerpen afspraken worden gemaakt: De functionaliteit van de te leveren diensten; Het niveau van de te leveren diensten;Per onderwerp moeten de afspraken (Service Level Elementen, SLE’s) wordenvastgelegd in een SLA.2.3 Wat is de definitie van een Service Level Agreement?Uit literatuurstudie blijkt dat er géén eenduidige betekenis is te ontdekken voor hetbegrip Service Level Agreement. Vanuit de bestudeerde literatuur is een beeldgevormd over wat een SLA is. Indien van toepassing zijn bronverwijzingenopgenomen naar de gehanteerde literatuur.Over de kern van het begrip bestaat wèl overeenstemming tussen de verschillendeauteurs die zijn geraadpleegd. Die kern houdt in dat een SLA een overeenkomst istussen een gebruikersorganisatie en een IT-serviceorganisatie waarbij een voor degebruikersorganisatie minimum aanvaardbaar serviceniveau wordt vastgelegd.Uit literatuuronderzoek 6 blijkt dat er nogal wat verschillende omschrijvingen wordengegeven van het begrip SLA. Vier voorbeelden daarvan: Een SLA is geen wettelijk contract, dat wil zeggen het heeft niet het waterdichtekarakter van een contract en geen wettelijke invloed. Clausules in een SLA zijnniet juridisch afdwingbaar. Een SLA is meer dan een resultaat van een onderhandelingsproces. Het wordtgecreëerd om de gemeenschappelijke opvattingen over de te leveren diensten5 ITIL Information Technology Infrastructure Library, versie 36 D. Vandaele en P. Gemmel, Service Level Agreements: een literatuuroverzicht 2004Afstudeerscriptie team <strong>801</strong> blz. 13 van 49


te bevorderen en de prioriteiten en verantwoordelijkheden vast te leggen.Conflictvermijding en verwachtingenmanagement van de klant is belangrijk.Een SLA dient naast de bindende afspraken met de bijbehorende prijs óók deverantwoordelijkheden van de klant te bevatten.In een SLA dient een formulering te worden opgenomen die bepaalt wat er moetgebeuren als een dienst niet geleverd wordt. Daarnaast moet de SLA eenschema bevatten met de kosten en middelen die nodig zijn voor de uitvoeringvan de overeenkomst.Naast de verschillende omschrijvingen kan uit de literatuur een aantal gemeenschappelijkekenmerken worden afgeleid. Eén van deze kenmerken is dateen SLA zowel door de gebruikersorganisatie als door de IT-serviceorganisatiegoedgekeurd en ondertekend moet worden. Dit betekent dat beide organisatiesverantwoordelijk zijn voor de in de SLA vastgelegde afspraken. Hierbij is het belangrijkdat de IT-serviceorganisatie zowel rekening houdt met de behoeften van degebruikersorganisatie als met de eigen mogelijkheden. Daarom moet voor hetbepalen van het serviceniveau een afweging worden gemaakt tussen deverschillende belangen. Er wordt gebruik gemaakt van verschillende criteria bij hetvastleggen van het minimale serviceniveau. Voor deze criteria worden normen enprestatiemaatstaven vastgelegd. Hierdoor wordt de te leveren dienstgekwantificeerd, meetbaar en tastbaar. Om een SLA controleerbaar te maken is hetbelangrijk op te nemen hoe de prestaties worden gemeten en met welke frequentieover de realisatie wordt gerapporteerd.2.4 Welke soorten Service Level Agreements zijn te onderkennen?Iedere gebruikersorganisatie heeft andere behoeften en verwachtingen zodatiedere SLA er anders uit ziet. Hierdoor ontstaan veel verschillende soorten SLA’s.Deze SLA’s kunnen in categorieën worden geordend , namelijk naar: De relatie tussen de betrokken organisaties; De structuur van de SLA; Het bindende karakter van de SLA.Hieronder worden de bovenstaande categorieën toegelicht: De relatie tussen de betrokken organisatiesVan een interne SLA is sprake als de afnemer van de dienst behoort tot deorganisatie die de dienst verleent. Ofwel: de gebruikersorganisatie en de ITserviceorganisatiebehoren tot dezelfde organisatie.Van een externe SLA is sprake als de afnemer van de dienst buiten de grenzen vande organisatie valt die de dienst levert. Ofwel: de gebruikersorganisatie en de ITserviceorganisatiebehoren niet tot dezelfde organisatie.Binnen de Rijksoverheid kunnen interne SLA’s nog verder worden onderverdeeld ininterdepartementale en intradepartementale. Wanneer een dienst wordt geleverddoor een bepaalde afdeling van een organisatie aan een andere afdeling vandezelfde organisatie wordt gesproken over intradepartementaal.Als de dienstverlening plaatsvindt tussen twee onderdelen van verschillendeministeries wordt over gesproken over interdepartementaal.Afstudeerscriptie team <strong>801</strong> blz. 14 van 49


Onderstaande figuur geeft de indeling naar de verschillende soorten encategorieën SLA’s weer:SLAInternExternInterdepartementaalIntradepartementaalVoor één dienstVoor één dienstVoor één dienstVoor alle dienstenVoor alle dienstenVoor alle dienstenFiguur 3: indeling soorten en categorieën SLA’s(bron: D. Vandaele en P.Gemmel, 2004) De structuur van de SLAEr worden in de geraadpleegde theorie drie structuren onderscheiden bezien vanuithet aantal gebruikersorganisaties en het aantal diensten die betrokken zijn bij deovereenkomst (zie figuur 2).Een eerste mogelijkheid: een IT serviceorganisatie kan per gebruikersorganisatie eenSLA opstellen voor alle te leveren diensten. Het voordeel is dat deze werkwijze eengoed overzicht verschaft en dat kan worden ingespeeld op de verschillendebehoeften van diverse gebruikersorganisaties. Het nadeel is wel dat bij eenverandering van de eisen van een gebruikersorganisatie de gehele SLA moetworden herzien.Een tweede mogelijkheid: een SLA kan worden afgesloten voor een bepaaldedienst die voor alle gebruikersorganisaties identiek is. Dit is alleen toepasbaar als degebruikersorganisaties niet teveel van elkaar verschillen. Het voordeel is dat dedienstverlening overzichtelijk is.Een derde mogelijkheid: een IT-serviceorganisatie kan voor elke dienst en elkegebruikersorganisatie een andere SLA opstellen. Het nadeel hiervan is dat dit leidt toteen groot aantal SLA’s waardoor de beheersing ervan wordt bemoeilijkt.Anderzijds biedt het ook voordelen: de SLA kan heel specifiek worden toegespitst opde wensen van de gebruikersorganisatie. Wanneer een gebruikersorganisatie hetniveau van een dienst wil wijzigen, hoeft slechts over één SLA onderhandeld teworden.Afstudeerscriptie team <strong>801</strong> blz. 15 van 49


In de literatuur worden verschillende methoden besproken voor het opstellen vaneen SLA 8 . Deze methoden laten veel overeenkomsten zien in de verschillendestappen in het proces.Om te komen tot een SLA moeten of kunnen de volgende stappen wordendoorlopen:1) De voorbereiding. Deze fase kan worden ingedeeld in vier stappen: De geschiktheid voor het invoeren van een SLA nagaan; Het vormen van een team bij zowel de gebruikers- als IT-serviceorganisatie;Het verzamelen van informatie als voorbereiding op de onderhandelingen;Het maken van afspraken over aansprakelijkheid en juridische aspecten dievastgelegd worden in het contract.2) Het onderhandelen over de inhoud van de SLA, bestaande uit: Het voorontwerp: bepalen van de structuur en inhoud van de SLA; De feedback van beide partijen: kritische beoordeling door personeelsledendie verantwoordelijk zijn voor het succesvol afhandelen van de SLA; En de pre-implementatie: het ontwikkelen van het prestatiemeetsysteem, hetopzetten van een rapporteringproces.3) Het beheer van de SLA. Over de volgende onderwerpen moeten afsprakenworden gemaakt: Een periodieke evaluatie van de inhoud van de SLA; De rapportering van de gerealiseerde diensten door de IT-serviceorganisatie; De procedure omtrent, en moment van, de herziening van de SLA.Om de bedrijfsprocessen en de IT-ondersteuning goed op elkaar afgestemd tekrijgen en te houden is het belangrijk dat de SLA wordt opgesteld voor een beperkteperiode en dat die regelmatig wordt aangepast aan de veranderingen in deorganisaties en aan de ontwikkelingen in de IT.Het is goed om een SLA te beschrijven in de terminologie van degebruikersorganisatie 9 . De bedrijfsdoelstellingen van de gebruikersorganisatiemoeten duidelijk naar voren komen in een SLA.Hierdoor kan de vertegenwoordiger van de gebruikersorganisatie eenvoudiger deafspraken en rapportages binnen de eigen organisatie communiceren. Daarnaast ishet dan voor de IT-serviceorganisatie mogelijk de dienstverlening te leveren diedaadwerkelijk aansluit op de doelstellingen van de gebruikersorganisatie.Een SLA moet worden gezien als een levend document en de gebruikersorganisatieen IT service- organisatie moeten periodiek met elkaar om tafel om teonderhandelen over de afspraken in de SLA.Ter illustratie is in bijlage 1 van deze scriptie een voorbeeld van een SLA opgenomenwaarin alle onderwerpen zijn benoemd die kunnen worden vastgelegd.8 I.J.M. van Gogh c.s. - Beveiliging en Service Level Agreements (2001)9 Wouter Wijlacker, Service Level Agreements gebaseerd op doelstellingen van de klant, SyntegraAfstudeerscriptie team <strong>801</strong> blz. 17 van 49


2.6.2 BetrokkenenHet is belangrijk dat bij het opstellen van een SLA de juiste personen van beideorganisaties aan tafel zitten. Dit omdat een gebruikersorganisatie een SLA wilhebben die toereikend is en de IT-serviceorganisatie een SLA wil hebben die(financieel) haalbaar is. Meestal worden SLA’s opgesteld in eensamenwerkingsverband tussen de Informatiemanager en de Service Level Manager.De Informatiemanager vertegenwoordigt de gebruikersorganisatie en heeft kennisvan de bedrijfsdoelstellingen en de wensen van de gebruikers. Hij opereert op hetsnijvlak van IT-expert en IT-gebruiker. De Service Level Manager vertegenwoordigt deIT-serviceorganisatie en houdt rekening met het beleid en de mogelijkheden van zijnorganisatie.2.7 Wat houdt beveiliging in vanuit IV-dienstverleningsperspectief?Uit de literatuur komt naar voren dat er in de afgelopen tijd een toenemendebehoefte waarneembaar is die betrekking heeft op het beschikbaar zijn en hetverstrekken van informatie. Dit uit zich vervolgens in een toename van de informatieuitwisselingtussen enerzijds de Rijksoverheid en anderzijds de burgers en bedrijven.Door gebruikersorganisaties binnen de Rijksoverheid worden steeds meer dienstenuitbesteed aan IT-serviceorganisaties. Bij deze uitbesteding blijft degebruikersorganisatie zelf verantwoordelijk voor die diensten. Daarom stelt zij eisenaan de IT-serviceorganisaties ten aanzien van de informatiebeveiliging. In dezeparagraaf wordt ingegaan op het ruimere begrip zoals dat bij de Rijksoverheid wordtgehanteerd, met als doel tot een goede begripsafbakening te komen.Beveiliging bestaat uit een aantal verschillende disciplines. Onder ‘integralebeveiliging’ 10 wordt verstaan: informatiebeveiliging, fysieke beveiliging en personelebeveiliging 11 . Bij informatiebeveiliging gaat het om betrouwbaarheidseisen. Bijfysieke beveiliging gaat het om veiligheidscriteria. En bij personele beveiliging gaathet om de wettelijke arbo-eisen.Om te komen tot een evenwichtig beveiligingspakket in een organisatie is hetbelangrijk de drie disciplines van beveiliging in samenhang te beschouwen. Dezevakgebieden liggen dicht tegen elkaar aan en overlappen elkaar gedeeltelijk.Voor het stellen van eisen aan IT-serviceorganisaties heeft met nameinformatiebeveiliging een directe betekenis, de eisen van de andere disciplineszullen verder niet worden behandeld.De drie beveiligingsaspecten resulteren in een stelsel van maatregelen, die zijnafgestemd op de te beschermen belangen. Binnen organisaties moetenrisicoafwegingen worden gemaakt door het onderkennen van afhankelijkheden enbedreigingen. Hierbij moet rekening worden gehouden met de geldende wet- enregelgeving.Binnen de Rijksoverheid zijn diverse voorschriften van kracht die ingaan opinformatiebeveiliging, waaronder bijvoorbeeld het Voorschrift InformatiebeveiligingRijksdienst 2007 (VIR 2007) 12 en het ‘Veiligheidsvoorschrift Rijksdienst 2005’ 13 .10 Douwe P. de Jong RSE, Integrale beveiliging, Dikke muren en firewalls, 200311 W. Barnhoorn c.s. - Outsourcing (2001)12 Besluit Voorschrift Informatiebeveiliging Rijksdienst (2007)Afstudeerscriptie team <strong>801</strong> blz. 18 van 49


Daarnaast worden binnen de Rijksoverheid diverse ‘best practices’ en anderevormen van wet- of regelgeving gehanteerd die betrekking hebben opinformatiebeveiliging: de Code voor Informatiebeveiliging en ITIL SecurityManagement. De genoemde voorschriften en ‘best practices’ worden nog korttoegelicht.Voorschrift Informatiebeveiliging Rijksdienst 2007De essentie van het VIR 2007 is ervoor te zorgen dat de overheid op eenbetrouwbare manier omgaat met gegevens van burgers en bedrijfsleven.De overheid is daarbij afhankelijk van informatietechnologie.Voor de beschikbaarheid van geautomatiseerde of handmatige informatiesystemenworden meestal Service Level Agreements (SLA) - of vergelijkbare overeenkomstenmet een andere benaming - afgesloten tussen de eigenaar van hetinformatiesysteem (uiteindelijk lijnmanagement) en de IT dienstenleverancier.Beveiliging is daarin een onderdeel van de afspraken.Veiligheidsvoorschrift Rijksdienst 2005Het ‘Veiligheidsvoorschrift Rijksdienst 2005’ geeft aan dat de secretaris-generaalverantwoordelijk is voor de integrale beveiliging van de organisatie, demedewerkers, het materieel, de informatiesystemen, de gebouwen en de overigeobjecten en de inrichting en de werking van de beveiligingsorganisatie.De secretaris-generaal wijst een beveiligingsambtenaar aan die deverantwoordelijkheid voor integrale beveiliging krijgt overgedragen.In het voorschrift is opgenomen dat onder integrale beveiliging wordt verstaan: eenafgewogen en consistente toepassing van beveiligingsmaatregelen in een breedscala van toepassingsgebieden. Het bedrijfsproces dient centraal te staan.Onder integrale beveiliging wordt niet verstaan de bedrijfsveiligheid.Er zijn verschillende ‘best practices’ die naast informatiebeveiliging in het algemeen,specifiek ingaan op SLA’s:In de Code voor Informatiebeveiliging 14 wordt op contractniveau - niet op hetgedetailleerde niveau van de SLA - ingegaan op beveiligingseisen die behoren bijuitbesteding. Om de bijbehorende beveiliging te regelen wordt een aantalmaatregelen geadviseerd, bijvoorbeeld op het gebied van fysiek- en logischtoegangsbeheer of het recht om te mogen auditen.ITIL is een ‘best practice’ voor IT-beheerprocessen. ITIL beoogt meer grip te krijgen opde kwaliteit van de IT-dienstverlening. Het basisprincipe van ITIL is, dat de ITserviceorganisaties diensten leveren aan de afnemers (gebruikersorganisaties) tegenwat heet ‘gerechtvaardigde kosten’. Het ITIL proces Security Management 15 geeftde structurele inpassing van beveiliging in de IT-beheerorganisatie en moet ervoorzorgen dat de dienstverlening blijft voldoen aan de met de klant afgesproken eisenop het gebied van de informatiebeveiliging.De SLA valt onder de verantwoordelijkheid van het Service Level Management enfungeert als stuurinstrument voor de ITIL-processen.In bijlage 2 zijn de bovengenoemde voorschriften en ‘best practices’ naderuitgewerkt terug te vinden.13 Veiligheidsvoorschrift Rijksdienst 200514 Code voor Informatiebeveiliging (NEN-ISO-IEC 17799:2005)15 J. Bon, G. Kemmerling en D. Pondman, IT servicemanagement, an introduction ITSMF (2002)Afstudeerscriptie team <strong>801</strong> blz. 19 van 49


3 Uitkomsten praktijkonderzoek3.1 InleidingIn dit hoofdstuk zijn de belangrijkste bevindingen weergegeven die vanuit de praktijknaar voren zijn gekomen. De informatie is verkregen door het houden van interviewsmet behulp van een gestructureerde vragenlijst (zie bijlage 3). De vragen voor deinterviews zijn thematisch geclusterd en ook op die wijze voorgelegd aan degeïnterviewden. Het doel van de interviews is: Het vaststellen of er naast de elementen genoemd in de literatuur nogelementen vanuit de praktijk naar voren komen die relevant zijn voor hetonderzoek; Nagaan of de bestudeerde literatuur toegepast is bij de voor het onderzoekgehanteerde casus; Het beantwoorden van de deelvragen.Om te beginnen is getracht inzicht te verkrijgen in wat in de praktijk wordt verstaanonder een SLA en wat de relevantie ervan is in de dagelijkse bedrijfsvoering vanzowel de gebruikersorganisatie als de IT-serviceorganisatie.Vervolgens is het totstandkomingsproces van een SLA in stukjes geknipt om zoduidelijkheid te verkrijgen over de te onderscheiden procesfasen die een SLAkenmerkt, gedurende zijn levenscyclus van ontwerp tot evaluatie.Als afsluiting van dit hoofdstuk wordt ingegaan op de meer inhoudelijke kant van deSLA. Daarbij is vooral gekeken naar de wijze waarop het gewenste kwaliteitsniveauvan de afspraken wordt bereikt. Tenslotte is ingegaan op de beveiligingsparagraaf:wat verstaat men onder beveiliging en hoe wordt het beveiligingsbegrip ingevuld.3.2 AlgemeenBetekenis van een SLAEen SLA wordt door de geïnterviewden omschreven als een overeenkomst tusseneen gebruikersorganisatie en een IT-serviceorganisatie. Dit blijkt te gelden voor allebetrokken partijen. De betekenis van de SLA is voor beide partijen identiek.Doel van een SLAVanuit de praktijk zijn verscheidene doelen van een SLA genoemd.Een SLA wordt gezien als een hulpmiddel om een abstract begrip als “goedfunctioneren” concreet te vertalen naar wederzijdse afspraken. De afspraken tussentwee partijen worden vastgelegd. Hierbij gaat het enerzijds om de wens en debehoefte vanuit de gebruikersorganisatie en anderzijds om de mogelijkheden vaneen IT-serviceorganisatie om de gevraagde dienst te kunnen leveren.In de SLA worden de afspraken over bijvoorbeeld taken, bevoegdheden enverantwoordelijkheden helder en eenduidig overeengekomen en vastgelegd.Hierdoor worden in een SLA de rechten en plichten van zowel degebruikersorganisatie als de IT-serviceorganisatie uitgewerkt. Aangegeven is dat hetreduceren van risico’s een belangrijk doel is van een SLA.Afstudeerscriptie team <strong>801</strong> blz. 20 van 49


Uitgangspunten en randvoorwaardenVanuit de praktijk is geconstateerd dat een SLA een document moet zijn dat leeft,en dus niet alleen wordt opgesteld om vervolgens in de spreekwoordelijke la teverdwijnen. Bewustwording van het belang is eveneens een belangrijkerandvoorwaarde om een SLA te laten functioneren zoals bedoeld.Een andere belangrijke randvoorwaarde die in de praktijk naar voren is gekomen isdat een SLA een beperkte looptijd/geldigheidsduur moet hebben, omdat de SLAdan kan worden aangepast aan de veranderende omgeving. Onder beperktelooptijd wordt hierbij ca. 12 maanden verstaan.3.3 Lifecycle van een SLAAanleiding van een SLADe aanleiding voor het opstellen van een SLA is het helder vastleggen van afsprakenover een te leveren dienst tussen twee partijen met als belangrijkste doel hetreduceren van mogelijke risico’s.De risico’s die gezien worden zijn bijvoorbeeld het niet nakomen van afspraken maarook onduidelijkheid over wat men van elkaar verwacht.Wanneer de IT-dienstverlening niet voldoet aan de overeengekomenbeheersdoelstellingen en dienstenniveaus, bestaat het risico dat degebruikersorganisatie haar bedrijfsdoelstellingen niet haalt en daarmee financiëleen/of reputatieschade lijdt. De IT-serviceorganisatie kan eveneens reputatieschadelijden en bij uitbesteding ook financiële schade lijden als er sprake is vanboetebepalingen.Ontwikkelen van een SLAUit de interviews is gebleken dat alle gebruikte SLA’s zijn gebaseerd op eenalgemeen aanvaard normenkader. Meestal aangereikt door de ITserviceorganisatie.Voor de in het onderzoek meegenomen casussen is gebruikgemaakt van ITIL. De redenen die aangegeven zijn voor het gebruik van ITIL zijn: De IT-serviceorganisaties zijn vaak ingericht op basis van de processenbeschreven in ITIL omdat zij het gebruiken voor het beheer van de ITinfrastructuur; Het in de IT-branche een veel gebruikte richtlijn is voor het beheer van ITinfrastructuur; Het praktische handvatten biedt voor uniform beheer van een steeds complexerwordende IT-infrastructuur.In de praktijk is aangegeven dat het bij de totstandkoming van een SLA belangrijk iseen goed team samen te stellen. Dit houdt in dat de juiste personen met elkaar omde tafel komen te zitten. Dit is een voorwaarde om de samenwerking tussen beideorganisaties succesvol te laten verlopen. Uit het onderzoek is gebleken dat debelanghebbenden van de IT-dienstverlening binnen de IT-serviceorganisatie enbinnen de gebruikersorganisatie worden betrokken bij de totstandkoming van deSLA. Hier kan het gaan om fysieke of “virtuele” teams. IT-auditors worden in depraktijk meestal achteraf ingeschakeld (bij een audit of ter verificatie) en mindervaak bij de opzet van een SLA.In een SLA moeten de afspraken over een te leveren dienst zoveel als mogelijkconcreet en meetbaar worden gemaakt.Afstudeerscriptie team <strong>801</strong> blz. 21 van 49


Dit is aangegeven als vanzelfsprekendheid, maar in de praktijk blijkt het meetbaarmaken van kwaliteitsnormen lastig te zijn. De perceptie van de gebruikersorganisatieblijkt anders dan die van de IT-serviceorganisatie.De rechten en plichten van zowel de gebruikersorganisatie als de ITserviceorganisatiemoeten ook in de SLA worden uitgewerkt. Aangegeven is dat ditniet altijd heel gedetailleerd gebeurt. Het risico bestaat dat verantwoordelijkhedenop organisatieniveau worden belegd en niet op het functionarisniveau, waardooronduidelijkheden ontstaan over wie waarvoor verantwoordelijk is.Transparantie is eerder in dit hoofdstuk al benoemd als doel van een SLA. In depraktijk blijkt echter dat voordat uiteindelijk transparantie wordt bereikt omtrent deovereengekomen afspraken er voorafgaand een intensief proces moet wordendoorlopen. In dit proces worden veel conceptversies tussen de beide partijenuitgewisseld totdat een definitieve versie wordt bereikt.Testen van een SLAMet het testen wordt bedoeld dat voordat een SLA operationeel wordt, wordtnagegaan of alle betrokkenen van een SLA de overeengekomen definitieveafspraken op eenzelfde wijze interpreteren. In de praktijk is gebleken dat testen geenexpliciet onderdeel is van het totstandkomingproces. Over een testprocedure lijktniet te zijn nagedacht. Alleen het uitwisselen van conceptversies wordt als een soorttestproces gezien.Gebruik van de SLAVoordat een SLA in gebruik genomen kan worden, is het noodzakelijk dat beidepartijen de SLA ondertekenen. Zonder ondertekening heeft een SLA geenrechtsgeldigheid en kunnen er geen rechten aan worden ontleend. Uit hetonderzoek is gebleken dat de SLA’s inderdaad worden ondertekend door deverantwoordelijke leidinggevenden in de organisaties.Zoals is aangegeven in dit hoofdstuk is een randvoorwaarde voor een goedewerking van een SLA dat het een ‘levend’ document moet zijn. Dit betekent datbetrokken partijen zich bewust zijn van de SLA en de hierin opgenomen afspraken.Tijdens het praktijkonderzoek is gebleken dat een SLA binnen een ITserviceorganisatiemeer leeft dan in een gebruikersorganisatie. In de gesprekken isaangegeven dat dit komt door een verschil in belangen: de gebruikersorganisatiewil dat de dienstverlening goed functioneert en het maakt hen weinig uit op welkewijze. De IT-serviceorganisatie daarentegen wil zich houden aan de afspraken in deSLA en voorkomen dat door de gebruikersorganisatie meer gevraagd wordt dan isafgesproken. Bij meningsverschillen tussen beide partijen over de dienstverlening valtde IT-serviceorganisatie vaak terug op de SLA.Binnen de Rijksoverheid wordt in het algemeen geen gebruik gemaakt vancontractuele SLA’s met boeteclausules. De Rijksoverheid vormt immers éénrechtspersoon waardoor geen sprake is van twee organisaties met verschillende(tegengestelde) belangen. Vanuit de interviews komt naar voren dat vanuit degebruikersorganisatie soms wel behoefte bestaat aan het opnemen van sancties ineen SLA voor het niet nakomen van de afspraken. De enige vorm die is aangetroffenis het (tijdelijk) opschorten van betalingen bij het niet nakomen van de gemaakteafspraken.Afstudeerscriptie team <strong>801</strong> blz. 22 van 49


Evaluatie van de SLARapportages over de gerealiseerde dienstenniveaus en beheersdoelstellingenworden door de IT-serviceorganisatie opgesteld en door de gebruikersorganisatiebeoordeeld. Vervolgens worden de rapportages besproken tussen beideorganisaties.Uit de praktijk is gebleken dat het belangrijk wordt gevonden, periodiek,bijvoorbeeld eens per jaar, de afspraken die vastgelegd zijn in de SLA te evalueren.Verder is gebleken dat de inhoud van de SLA overigens zelden wordt aangepast. Erworden daarentegen wel aanvullende afspraken gemaakt.3.4 Inhoud van een SLA (algemeen)BedrijfsdoelstellingenEen relatie tussen de (bedrijfs)doelstellingen van de gebruikersorganisatie en deverwoording ervan in de SLA ligt voor de hand. Immers, de te verrichtenwerkzaamheden door de IT-serviceorganisatie kunnen op die manier in lijn wordengebracht met de resultaten die de gebruikersorganisatie wil bereiken.Bedrijfsdoelstellingen zijn echter niet aangetroffen in de SLA’s.Als de gebruikersorganisatie zijn doelstellingen echter vertaalt in heldere eisen voorde IT-serviceorganisatie, is het verwoorden van de bedrijfsdoelstellingen overbodig.Samenstelling SLAIn de onderzochte praktijk is gebleken dat bij het opstellen van een SLA gebruikgemaakt wordt van een template of standaard SLA die door de IT-serviceorganisatiewordt aangereikt. Deze gehanteerde templates zijn gebaseerd op de ITILbeheerprocessen.KwaliteitsniveauUit het onderzoek is gebleken dat het kwaliteitsniveau van een SLA voor een grootdeel wordt bepaald door hoe de afspraken zijn gemaakt en vastgelegd. Vanuit depraktijk is aangegeven dat het voor de hand ligt dat afspraken helder, concreet enmeetbaar moeten zijn. Hoe concreter de afspraken zijn gemaakt hoe beterwerkbaar ze zijn. Een voorbeeld daarvan zijn de tijdstippen waaropverantwoordingsrapportages worden opgeleverd, bijvoorbeeld één keer perkwartaal. Daarnaast wordt in de praktijk meestal de inhoud en opbouw van derapportages eenduidig - en van te voren - vastgelegd.Naast het maken van concrete afspraken is aangegeven dat het belangrijk is dat deovereengekomen afspraken voor beide partijen op dezelfde wijze wordengeïnterpreteerd. Voor het vaststellen van het kwaliteitsniveau van de geleverdedienstverlening en het vereiste beveiligingsniveau ligt het voor de hand omkwaliteitsnormen af te spreken. Vervolgens kunnen die normen in meetbareeenheden worden vertaald.Zowel het definiëren van die kwaliteitsnormen als het meten ervan blijkt echter eenlastige opgave te zijn. Dit heeft met name te maken met de verschillende perceptiesvan de gebruikers- en IT-serviceorganisatie over dezelfde onderwerpen.In de SLA’s wordt niet vastgelegd welk normenkader wordt gehanteerd in relatie totde informatiebeveiliging.Afstudeerscriptie team <strong>801</strong> blz. 23 van 49


3.5 Inhoud van een SLA (beveiliging)Wat is beveiliging?In ons onderzoek geven de partijen waarmee is gesproken een eenduidig antwoordop de vraag wat onder beveiliging wordt verstaan. De kwaliteitsaspectenbeschikbaarheid, integriteit en exclusiviteit worden in alle gevallen spontaangenoemd.VIR en ITILBinnen de Rijksoverheid weten zowel de gebruiker als de dienstverlener zich aan hetVIR gebonden. Vaak is het VIR doorvertaald naar interne richtlijnen die specifiekgelden voor een departement of organisatieonderdeel. Dat wordt dus ook alsuitgangspunt gehanteerd. Omdat de IT-serviceorganisatie vaak het meestebijdraagt aan de totstandkoming van een SLA, ligt het voor de hand dat ITIL wordtgebruikt als referentiekader. ITIL sluit immers goed aan bij de technische processenvan de IT-serviceorganisatie. Alle bekeken SLA’s waren op ITIL gebaseerd.RichtlijnenUit de gesprekken is naar voren gekomen dat er veel interne richtlijnen bestaan waarde Rijksoverheid zich aan dient te houden. In de loop van de tijd worden vaakrichtlijnen toegevoegd en vinden er aanpassingen plaats.Momenteel is een duidelijk tegengestelde beweging ingezet: het doelbewustverminderen van het aantal en de omvang van de richtlijnen, waardoor meerduidelijkheid en eenduidigheid wordt bereikt. Daarnaast is aangegeven dat derichtlijnen ook bekend moeten zijn bij de betrokken medewerkers. Er is nog wel eenssprake van een dik boek dat ‘in de kast staat’, dat niet wordt gelezen en waarvande inhoud maar mondjesmaat bekend is.Het inzetten van ondersteunende technische hulpmiddelen (bijvoorbeeldbeeldkrantberichten) en mondelinge voorlichting om zowel bewustwording alsbekendheid met de afspraken en regels te vergroten wordt daarom als bruikbaargereedschap gezien en regelmatig ingezet.Afstudeerscriptie team <strong>801</strong> blz. 24 van 49


4 Het auditinstrument4.1 InleidingIn dit hoofdstuk worden de antwoorden gegeven op de drie laatste deelvragen diezijn afgeleid uit de centrale onderzoeksvraag:9. Waaraan moet een Service Level Agreement voldoen?10. Waaraan moet het proces van totstandkoming en gebruik van een Service LevelAgreement voldoen?11. Hoe kan getoetst worden of in de Service Level Agreement de essentiëleonderwerpen zijn benoemd?Het antwoord op de vragen 9 en 10 is samengebracht in een auditinstrument.Dit instrument bevat de hoofd- en subcategorieën die een rol spelen bij zowel debeoordeling van de inhoud van een SLA als het tostandkomingsproces ervan.Het instrument wordt hierna toegelicht.Het antwoord op vraag 11, de toetsing van de SLA, kan worden gegeven door de inhet instrument opgenomen vragen te stellen en te beantwoorden.De mate waarin de vragen positief kunnen worden beantwoord is een goedcriterium voor de kwaliteit van de SLA.4.2 Het instrumentOp basis van theorie (H2) en praktijk (H3) zijn er zowel overeenkomsten als verschillenvastgesteld. Sommige kenmerken uit de theorie worden bevestigd door de praktijk.De overeenkomsten zijn: Een SLA dient ter verduidelijking en het vastleggen van de afspraken tussen teopdrachtgever (gebruiksorganisatie) en de dienstverlener (IT-serviceorganisatie); Een SLA is bedoeld om de verwachtingen te managen en erop te kunnen sturen; De samenstelling van een team met de juiste competenties is een voorwaardevoor succes bij het opstellen en gebruik van een SLA; Er bestaat geen template van een “ideaal-SLA”, maar er is wel een set metonderdelen die er in ieder geval in thuishoren; Onder “beveiliging” wordt verstaan: beschikbaarheid, integriteit envertrouwelijkheid; Bij de Rijksoverheid geldt het VIR voor beide partijen en wordt ook als zodanigonderkend. Het ITIL is met name van toepassing op de IT-serviceorganisatie enwordt intensief toegepast. Voor de gebruikersorganisatie kan gebruik wordengemaakt van BiSL, maar dit komt niet erg prominent naar voren; Beveiliging vormt een integraal onderdeel van een SLA, maar wordt niet alsbijzonder onderdeel gezien en behandeld.Afstudeerscriptie team <strong>801</strong> blz. 25 van 49


Er zijn ook enkele verschillen te constateren. De belangrijkste daarvan zijn: Het lijkt evident dat een SLA een ‘levend document’ hoort te zijn. In de praktijkwordt dat sterk benadrukt. In de theorie wordt weliswaar aangegeven dat detotstandkoming van een SLA een actief proces is tussen beide partners, maarover de fase ná de totstandkoming rekening houdend met allerandvoorwaarden, wordt niet veel gezegd; In de theorie vormt de testfase een wezenlijk onderdeel van eenontwikkelproces. In de praktijk wordt dat niet vertaald naar een concreteactiviteit die vóór ingebruikname van de SLA dient plaats te vinden; Er zijn eenduidige normen beschikbaar die betrekking hebben opinformatiebeveiliging. Ze worden misschien wel toegepast, maar niet vastgelegdin de SLA’s. Ook over de toetsing van de werking ervan worden geen afsprakengemaakt.Door de theorie en de bevindingen vanuit het praktijkonderzoek over de opzet, hetbestaan en de werking van een SLA, met elkaar in verband te brengen is eeninstrument tot stand gekomen. Het is opgenomen in bijlage 4. Dit instrument kangebruikt worden door een adviseur die wordt gevraagd om de totstandkoming vaneen goede SLA te begeleiden of door een auditor om de kwaliteit van eenbestaande of reeds ontwikkelde SLA te beoordelen.Het instrument is opgebouwd in de vorm van een tabel. De tabel is verdeeld in 4kolommen. De eerste kolom bevat de hoofdcategorieën. Deze hoofdcategorieënzijn ingedeeld op dezelfde wijze als genoemd in hoofdstuk 2:algemeen, lifecycle van een SLA, inhoud van een SLA algemeen en inhoud specifiekmet betrekking tot het onderwerp informatiebeveiliging.In tabelvorm, onderdeel van het auditinstrument ziet dat er als volgt uit:HoofdcategorieAlgemeenLifecycle SLAInhoud van een SLA(algemeen)Inhoud van een SLA(beveiliging)Vervolgens zijn in de tweede kolom per hoofdcategorie, subcategorieënopgenomen. Voor de hoofdcategorie ‘Algemeen’ zijn de volgende onderwerpenbenoemd: doelen, randvoorwaarden en uitgangspunten en rechten en plichten.Voor ‘Lifecycle van een SLA’ zijn deze onderwerpen benoemd: aanleidingtotstandkoming SLA, ontwikkelen, testen, gebruik en evaluatie van de SLA.Met betrekking tot de hoofdcategorie ‘Inhoud van een SLA algemeen’, zijn devolgende onderwerpen opgenomen: bedrijfsdoelstellingen, samenstellen van eenSLA en het kwaliteitsniveau.Afstudeerscriptie team <strong>801</strong> blz. 26 van 49


De laatste hoofdcategorie, ‘Inhoud van een SLA met betrekking tot het onderwerpbeveiliging’, bevat de volgende onderwerpen: begrip beveiliging, referentiekaders,regelgeving en incidenten. Zie de volgende tabel.HoofdcategorieAlgemeenLifecycle SLAInhoud van een SLA(algemeen)Inhoud van een SLA(beveiliging)SubcategorieDoelenRandvoorwaarden enuitgangspuntenRechten en plichtenAanleidingtotstandkoming SLAOntwikkelenTestenGebruik van de SLAEvaluatie van de SLABedrijfsdoelstellingenSamenstellen SLAKwaliteitsniveauBegrip ‘Beveiliging’ReferentiekadersRegelgevingIncidentenDe derde kolom van de tabel geeft per subcategorie vervolgens deaandachtspunten en vragen weer die zowel gesteld kunnen worden aan de teinterviewen personen bij de gebruikersorganisatie als bij de IT-serviceorganisatie.Voorbeelden van deze vragen zijn: Is het doel van de SLA bekend bij de betrokken partijen? Is er voor de totstandkoming van de SLA een team samengesteld? Zijn alle afspraken/servicelevels in de SLA concreet en meetbaar?De opgenomen vragen zijn allemaal zogeheten ‘gesloten vragen’ en kunnen dusmet ja of nee beantwoord worden. Hiermee kan snel inzicht worden verkregen of inhoofdlijnen aan de belangrijkste onderwerpen aandacht is besteed. Hieronder is, terverduidelijking, een deel van het instrument weergegeven:Lifecycle SLA Gebruik van de SLA Is de SLA door beide partijenondertekend?Is de SLA een “levend document” voorbeide betrokken partijen?Zijn er sancties opgenomen in de SLA?J/NJ/NJ/NDe volledige tabel is opgenomen in bijlage 4.In aanvulling op deze tabel is een vragenlijst toegevoegd waarmee dieper wordtingegaan op de genoemde categorieën.Deze vragen kunnen behulpzaam zijn als, in eerste instantie, het antwoord op éénvan de genoemde vragen uit de tabel ontkennend is.Op dat moment kunnen aanvullende vragen worden gesteld om inzicht in deactuele situatie te verkrijgen.Afstudeerscriptie team <strong>801</strong> blz. 27 van 49


5 Conclusies en aanbevelingenDit hoofdstuk omvat de conclusies en aanbevelingen die zijn voortgekomen uit debevindingen vanuit het onderzoek dat is uitgevoerd om tot deze scriptie te komen.De centrale onderzoeksvraag van deze scriptie luidt als volgt:Op welke wijze kan worden getoetst of aan de eisen wordt voldaan die aan eenService Level Agreement (SLA) worden gesteld, om de afstemming tussen degebruikersorganisatie en de IT-serviceorganisatie binnen de Rijksoverheid vast teleggen, waarbij ook de noodzakelijke informatiebeveiliging in opzet, bestaan enwerking in de IV-dienstverleningsketen is geborgd?Uit het literatuur- en praktijkonderzoek blijkt dat een SLA een nuttig middel is omafspraken tussen twee organisaties eenduidig vast te leggen. Er zijn elementen naarvoren gekomen die belangrijk zijn voor de totstandkoming van een SLA, maar ookbelangrijk zijn bij de toetsing van het gebruik van een SLA. Het is mogelijk geblekendeze elementen te vatten in een auditinstrument. Dit auditinstrument kan gebruiktworden door een auditor of adviseur om een SLA te toetsen of aan de eisen wordtvoldaan die aan een SLA worden gesteld.In het auditinstrument zijn de elementen in de volgende hoofd- en subcategorieëningedeeld: Algemeen, bijvoorbeeld doelen, rechten en plichten; Lifecycle van een SLA, bijvoorbeeld aanleiding, ontwikkelen en testen; Inhoud van een SLA (algemeen), bijvoorbeeld samenstelling; Inhoud van een SLA (beveiliging), bijvoorbeeld referentiekaders en regelgeving.De elementen uit deze categorieën moeten in ieder geval worden meegenomen bijde totstandkoming van een SLA om te zorgen voor een goede afstemming tussenbeide partijen.De noodzaak voor het gebruik van een dergelijk auditinstrument wordt gevoed doorde discrepantie die er is tussen de theorie en de praktijk. Om dat verschil goed tekunnen toetsen en om te beoordelen of de afstemming wel volledig is, kan hetinstrument behulpzaam zijn.Het instrument is (nog) niet gevalideerd. Geadviseerd wordt dit in eenvervolgonderzoek te doen. In dit vervolgonderzoek kan ook worden nagegaan ofhet zin heeft om weegfactoren toe te kennen aan de onderscheiden categorieënvan het instrument.De praktische bruikbaarheid van de voorgestelde methodiek kan op deze wijzeworden vastgesteld en wellicht op onderdelen nog worden verfijnd of verbeterd.De toetsing van het instrument in de praktijk heeft in dit onderzoek opgeleverd datde normenkaders voor informatiebeveiliging niet worden vastgelegd in de SLA’s enook niet op werking zijn gecontroleerd door de naleving ervan te toetsen.Een aanbeveling is dan ook om dit wel te gaan doen, bijv. door het gebruik makenvan een Third Party Mededeling (TPM), die betrekking heeft op het niveau van deinformatiebeveiliging (conform het VIR 2007) en wordt afgegeven door eenonafhankelijke partij.Afstudeerscriptie team <strong>801</strong> blz. 28 van 49


6 ReflectieAlgemeenHet maken van een scriptie vergt nogal wat. Je moet tijd investeren, werken aan deonderlinge communicatie met elkaar en begeleiders. Lezen van literatuur, hetmaken van afspraken en het houden van interviews met in eerste instantie somsvolstrekt onbekende mensen. Tijdens het totstandkomingproces is ons een aantaldingen opgevallen. Een paar daarvan willen we in dit hoofdstuk met u delen.Planning en tijdsduurDe VU hanteert voor het schrijven van een scriptie een termijn van zes maanden. Alsrichtlijn voor de studiebelasting wordt 200 uur per persoon aangegeven. Om nietonnodig onder tijdsdruk te komen staan, hebben wij besloten eerder te starten methet schrijven van een scriptie, namelijk in april 2007. Dat is achteraf niet onverstandiggebleken. Het schrijven van een plan van aanpak heeft veel tijd gekost, maar deervaring is dat wanneer hier goed over nagedacht wordt de tijd wordtterugverdiend in de uitvoeringsfase van het onderzoek. Een langere doorlooptijddan de geadviseerde termijn is aan te raden om de werkdruk meer te spreiden.Wijziging aanpakDe initiële aanpak voor het onderzoek bleek tijdens de uitvoering van het onderzoektoch niet de aanpak te zijn die zou leiden tot het gewenste resultaat. Deze initiëleaanpak ging uit van het opstellen van een instrument op basis van de bestudeerdetheorie. Dit instrument zou gevalideerd worden in het praktijkonderzoek. Het bleekechter dat de theorie onvoldoende handvatten bood om te komen tot eendergelijk instrument. Daarom hebben wij gekozen de aanpak te wijzigen en op basisvan de bestudeerde theorie een vragenlijst op te stellen zodat wij daarmee hetpraktijkonderzoek konden uitvoeren. Met de informatie vanuit de theorie enverkregen uit het onderzoek hebben wij vervolgens het instrument samengesteld.Informatiebeveiliging: een precair onderwerpVoordat wij begonnen aan het onderzoek waren wij niet echt bekend met hetgekozen onderwerp. Ons onderzoek was in eerste instantie gericht op debeveiligingsaspecten. De aanleiding voor ons was de onderwaardering van hetonderwerp beveiliging in een SLA. We hebben ervaren dat dit onderwerp somsgevoelig ligt. In voorkomend geval wilden we bij een sector van een groterijksoverheidsdienst gesprekken voeren en interviews afnemen. Over beveiligingkonden we op papier en in de SLA’s niet erg veel terugvinden.Toen bleek dat diverse gesprekspartners enigszins terughoudend werden.De publicatie bij de VU, de veronderstelde mogelijke (politieke) risico’s, wellicht detekortkomingen van de organisatie op dit terrein: het resulteerde er in dat dit deelvan het onderzoek voortijdig eindigde.Een aanbeveling die wij willen doen aan toekomstige studenten van de VU: weesalert op mogelijke hindernissen die worden opgeworpen in samenhang met dekeuze van het scriptieonderwerp. Je onderzoek kan erop stuklopen.Kies met zorg een onderwerp en een probleemstelling.Afstudeerscriptie team <strong>801</strong> blz. 29 van 49


LiteratuurlijstDe opgenomen nummers achter de literatuur corresponderen met de voetnoten inde scriptie.Boeken: J.H.J. van den Heuvel, Hoe schrijf ik een scriptie of these? (1)Uitgever Lemma B.V. Utrecht, 2004 Umberto Eco, Hoe schrijf ik een scriptie? (2)Uitgeverij Pockethuis, 2005 D.B. Baarda &M.P.M. de Goede, Basisboek Methoden en (3)Technieken Wolters-Noordhoff B.V. , 2002 Ir. P.F.L. van Scheffel, Het doel, de weg en de rugzak, (7)Uitgever, Verdonck, Klooster & Associates B.V, 2004 I. van Gogh, W.H.M. Hafkamp, P.M. Hoogendoorn e.a., (8)Beveiliging en Service Level Agreements, Uitgever SDU, 2001 W. Barnhoorn, E. Cramwinckel, I. van Gogh e.a., Outsourcing. (11)Uitgever SDU, 2001 J. Bon, G. Kemmerling en D. Pondman, IT Service management: an (15)introduction ITSMF, uitgeverij Van Haren Publishing, 2002Voorschriften/richtlijnen/’frameworks’: Besluit Voorschrift Informatiebeveiliging Rijksdiensten (2007) (12) Veiligheidsvoorschrift Rijksdienst 2005 (13) Code voor Informatiebeveiliging (NEN-ISO-IEC 17799:2005) (14) ITIL Information Technology Infrastructure Library (versie 3) (5) BISL Business Information Services Library (4)(English - Dutch version 1.0 June 2007)Artikelen: Wouter Wijlacker, Service Level Agreements gebaseerd op (9)doelstellingen van de klant, Syntegra D. Vandael en P. Gemmel, Service Level Agreements: (6)een literatuuroverzicht, 2004 Douwe P. de Jong RSE, Integrale beveiliging, dikke muren en (10)firewalls, 2003Afstudeerscriptie team <strong>801</strong> blz. 30 van 49


BijlagenBijlage 1 - aspecten van een SLA1. Aandachtspunten Service Level AgreementWaarschuwing:Deze checklist Service Level Agreement is een globale lijst van aandachtspunten dierelevant zijn voor het opstellen van een SLA. Er wordt weinig in detail getreden,omdat het toesnijden op iedere individuele praktijksituatie ondoenlijk is. Er kan nietingegaan worden op de afbreukrisico’s die gelopen worden in uw specifiekesituatie. Door SLA’s moeten juist deze risico’s geminimaliseerd worden en vervolgensdienen de allocatie en maatregelen vast gelegd te worden. Deze problematiek is inhet geheel niet af te vangen met deze standaardchecklist. Afhankelijk van desituatie waarvoor een SLA opgesteld dient te worden is er meer of minder maatwerknodig.2. Inhoud SLAIn dit hoofdstuk zijn de artikelen opgenomen die van belang zijn bij het opstellen vaneen Service Level Agreement. Aangezien het opstellen van contracten altijd eenstukje maatwerk is, kan deze checklist uitsluitend als basis dienen.2.1 Identificatie van partijenBeschrijving van de partijen die betrokken zijn bij de overeenkomst.namen (eventueel aangevuld met afkortingen, die in de SLA gebruikt worden);locaties (adressen, in geval van een groot aantal, deze opnemen in de bijlage);overeenkomstnummer (met versienummer).2.2 Uitgangspunten2.2.1 Definities en afkortingenLijst met sluitende en duidelijk gedefinieerde begrippen, afkortingen, formules enmeetvoorschriften, die misverstanden helpen voorkomen.• overzicht van in de SLA gebruikte definities;• overzicht van in de SLA gebruikte afkortingen (geen afkortingen van denamen van de deelnemende partijen);• overzicht van in de SLA gebruikte (algemene) formules en meetvoorschriften;• overzicht van in de SLA gebruikte (algemene) tijdstippen van aanvang enbeëindiging aan de hand van meetbare parameters.2.2.2 Inleiding en uitgangspuntenPlaatsing van inleidende opmerkingen (bijvoorbeeld dat een SLA is opgesteld terverbetering van de kwaliteit van de dienst) en uitgangspunten (bijvoorbeeld het feitdat personen gerechtigd moeten zijn om de dienst te gebruiken of het nietbeschikbaar stellen van diensten aan derden).• inleidende opmerkingen met betrekking tot de doelstellingen en de inhoud;• uitgangspunten met betrekking tot het beschikbaar stellen van de dienst.Afstudeerscriptie team <strong>801</strong> blz. 31 van 49


2.2.3 Onderwerp van overeenkomstAangeven op welke dienst (of diensten) de SLA betrekking heeft.• korte beschrijving van de diensten waar de SLA betrekking op heeft (in relatiefgrote SLA’s) middels een zinsnede als “Het verzorgen van ......”;• afsluiting van deze clausule met “Het beheren, onderhouden en instandhouden van de hierboven genoemde voorzieningen tegen de in debijbehorende detailovereenkomsten genoemde prestatiecriteria”.2.3 Randvoorwaarden2.3.1 Aard en omvang van de overeenkomstBeschrijving van de onderdelen waar de dienst betrekking op heeft, zoals deorganisaties (en/of bepaalde afdelingen) die de dienst afnemen, de juridische statusvan de overeenkomst en een verwijzing naar algemeen geldende voorwaarden.• omvang (geldigheid van de SLA voor delen van de cliëntorganisatie);• juridische status en versie van de SLA;• algemene voorwaarden;• overige opmerkingen met betrekking tot de aard en de omvang van deovereenkomst.2.3.2 Beschrijving van de dienstVerwijzing per geleverde dienst naar de betreffende service level specificaties, dieopgenomen zijn in de verschillende detailovereenkomsten of bijlagen.• concrete beschrijving van diensten (verwijzing naar service level specificatiesuitgewerkt per dienst);• servicetijden (normale servicetijden, weekends, feestdagen envakantiedagen);• service beschikbaarheid (minimumpercentages, gemiddelde, maximaalaantal verstoringen per periode, meetperiode);• serviceprestaties.2.3.3 AfbakeningExpliciete beschrijving van de grenzen van de dienstverlening, zowel met betrekkingtot de te leveren diensten zelf, als ook tot de hiervoor benodigde middelen.• afbakenen van de dienst;• afbakenen van de automatiseringsmiddelen.2.4 Duur en beëindiging van de overeenkomstBepaling waarin wordt aangegeven voor welke periode de SLA geldt en hoe destandaardprocedure voor verlenging of beëindiging van de SLA luidt.• duur van de overeenkomst (begin- en einddatum);• procedure voor verlenging en beëindiging;• bijzondere omstandigheden (eventueel met directe beëindiging als gevolg).Afstudeerscriptie team <strong>801</strong> blz. 32 van 49


2.5 Overlegstructuren, contactpersonen en correspondentieVastleggen wanneer gestructureerd overleg plaatsvindt, wie er aan dit overlegzullen deelnemen en wie bij beide partijen verantwoordelijk is voor de onderlingerelatie. Tevens zal een overzicht opgenomen worden van alle contactpersonen enverantwoordelijken bij escalatie of calamiteiten.• tijdstippen of aanleidingen voor overleg;• betrokken personen bij overleg;• verantwoordelijke personen voor de onderlinge relatie;• overzicht van contactpersonen en verantwoordelijken (inclusieftelefoonnummers) bij escalatie en/of calamiteiten (meestal een verwijzingnaar de betreffende bijlage);• overzicht van post- en bezoekadressen van betrokken organisaties en locaties(meestal een verwijzing naar de betreffende bijlage);• standaardformulieren voor onderlinge correspondentie (meestal eenverwijzing naar de betreffende bijlage).2.6 Eigendom en risicoBepaling van de eigenaar van de apparatuur en programmatuur die nodig is voorhet leveren van de dienst, eventueel uitgebreid met een beschrijving van deverantwoordelijk persoon voor achteruitgang of tenietgaan van deze middelen.• eigenaar van benodigde apparatuur en programmatuur;• noemen van organisatie bij wie het risico van tenietgaan of achteruitgangvan apparatuur en/of programmatuur ligt;• opmerkingen over achteruitgang als gevolg van opzet of bewusteonzorgvuldigheid.2.7 BeveiligingBeveiliging van systemen, services en data zijn belangrijke aspecten. Dezeonderdelen dienen dan ook beschermd te worden tegen interne en externeaanvallen.• procedure van beveiliging van systemen, services, data;• maatregelen bij het schenden van beveiligingsprocedures;• aanspreekpunt bij beveiligingsincidenten.2.8 RapportageAls opdrachtgever dient u zicht te hebben, te krijgen en te houden op alles wat temaken heeft met het informatiesysteem. Omtrent de rapportage moeten afsprakengemaakt worden betreffende:• inhoud van de rapportage;• verschijningsfrequentie;• distributie (functionarissen, afdelingen, etc.).Afstudeerscriptie team <strong>801</strong> blz. 33 van 49


2.9 Aanpassingen van de SLA2.9.1 Wijziging van de dienstSchetsen van mogelijkheden voor het wijzigen van de dienst (zowel door deleverancier als door de afnemer) indien dit noodzakelijk of wenselijk wordt geacht.Tevens wordt beschreven hoe en wanneer wijzigingsverzoeken ingediend kunnenworden en in welke mate het wijzigen van de dienst een herziening van de SLAnoodzakelijk maakt. Vast te leggen items zijn:• wijzigingsprocedure inclusief het noemen van het meldpunt (meestal dehelpdesk) en aanmeldingsperiode voor wijzigingen;• wijze van overleg over wijzigingsverzoeken;• impact van wijziging op de SLA (eventueel een opmerking in de trant van“wijziging van de dienst, zoals installatie van nieuwe hard- en/of software,maakt herziening van de SLA in beginsel noodzakelijk”).2.9.2 Herziening van de SLABeschrijving van de procedure voor het wijzigen van de SLA en de regeling metbetrekking tot de looptijd van de SLA. Bij omvangrijke SLA’s loont het tevens demoeite om te beschrijven, wanneer vorige wijzigingen aan de SLA uitgevoerd zijn enwat er destijds gewijzigd is aan de SLA, zodat op eenvoudige wijze terug te zoeken iswelke versies de SLA heeft gekend. Vast te leggen items zijn:• opsomming van zaken die leiden tot een wijziging van de SLA;• wijzigingsprocedure (wijze, tijdstip, overleg);• verlenging van de looptijd van de SLA, bijvoorbeeld stilzwijgend, door middelvan berichtgeving of na onderling overleg;• vorige wijzigingen en versies van de SLA, inclusief de data waarop deverschillende versies in gebruik waren.2.10 Financiële vergoeding2.10.1 PrijzenDe hoogte van de vergoeding die betaald moet worden dient te wordenvastgelegd, inclusief grenzen aan stijgingen. Hierdoor krijgt de opdrachtgeverzekerheid met betrekking tot de jaarlijkse kosten. Vast te leggen items zijn:• opdrachtgever zal een vergoeding van € ....... per ........ voldoen in ...........termijnen van € ....;• prijzen in valuta .. , inclusief of exclusief BTW;• prijsstijgingen gemaximaliseerd tot ..% per ..... of maximale prijsstijgingenconform consumenten prijsindex cijfer van CBS.2.10.2 BetalingAfspraken aangaande betaling van overeengekomen vergoedingen dienen teworden vastgelegd om onduidelijkheden en/of problemen hieromtrent tevoorkomen. Vast te leggen items:• betalingstermijn .. dagen na facturering;• op welk bank-/girorekeningnummer betaald dient te worden;• welke regels gelden er bij te late betaling;• wat te doen indien opdrachtgever niet akkoord gaat met de factuur.Afstudeerscriptie team <strong>801</strong> blz. 34 van 49


2.11 Verantwoordelijkheid, escalatie en reclame2.11.1 Verantwoordelijkheid, aansprakelijkheid en strafbepalingenVermelding van zowel de aansprakelijkheid voor de bij de cliëntorganisatieopgestelde apparatuur en/of programmatuur als van de aansprakelijkheid van deleveranciersorganisatie voor het functioneren van de cliëntorganisatie.• aansprakelijkheid van leveranciersorganisatie voor functioneren vancliëntorganisatie, bijvoorbeeld in geval van storingen of calamiteiten;• gevolgen van het niet (volledig) nakomen van afspraken;• verhalen van schade als gevolg van een onvoldoende functionerendedienst;• beschrijving van overleg in geval van problemen (eventueel het verwijzennaar de clausule over geschillen);• boeteclausules of andere financiële strafbepalingen.2.11.2 Beperkingen, afhankelijkheden en overmachtVastlegging van beperkingen met betrekking tot het gebruik van de te leverendiensten, de afhankelijkheid van derde organisaties (bijvoorbeeld KPN t.b.v.communicatie) en het schetsen van situaties waarin de organisaties zich kunnenberoepen op overmacht.• maximaal aantal gelijktijdige gebruikers van de verschillende diensten;• maximaal aantal toegelaten gebruikers (maximaal aantal “accounts”) vande verschillende diensten;• afhankelijkheid van andere organisaties of diensten;• regeling met betrekking tot het beroepen op overmacht, inclusief demogelijkheid tot het buiten werking stellen van de SLA en de te ondernemenacties om zo spoedig mogelijk terug te kunnen keren naar de normalesituatie;• algemene calamiteitenprocedure, inclusief een verwijzing naar deverschillende calamiteitenplannen;• overige beperkingen (bijvoorbeeld het maximaal aantal transacties perperiode).2.11.3 Geheimhouding, verantwoordelijkheid en concurrentiebedingAfspraken met betrekking tot het niet openbaar maken of aan derden beschikbaarstellen van vernomen informatie tijdens het opstellen van de SLA (inhoudelijke SLAbepalingen)of het functioneren van de dienst (informatie verkregen door databaseopvragingendient als vertrouwelijk te worden aangemerkt). Tevens kunnenbepalingen worden opgenomen voor bescherming tegen het overnemen vanpersoneel (concurrentiebeding) of het rechtstreeks onderhandelen van decliëntorganisatie (buiten de leverancier om) met derden over de levering van (delenvan) diensten.• afspraken met betrekking tot geheime of vertrouwelijke informatie;• concurrentiebeding, bijvoorbeeld aangaande het overnemen van personeel.Afstudeerscriptie team <strong>801</strong> blz. 35 van 49


2.11.4 GeschillenBeschrijving van het feit wanneer onderling overleg plaatsvindt en wat de procedureis bij het optreden van onderlinge conflicten of geschillen qua afhandeling en hetbetrekken van derde partijen.• procedure;• onafhankelijke derde instantie of persoon;• feit of een uitspraak van een onafhankelijke arbiter bindend is of niet.2.12 Slotbepaling en handtekeningenFormele afsluiting van de SLA, waarin gesteld wordt dat de betrokken partijen “hetbovenstaande” overeengekomen zijn ondertekend door verantwoordelijkepersonen uit beide organisaties.• formele afsluiting;• namen en handtekeningen van tekengerechtigde personen.Afstudeerscriptie team <strong>801</strong> blz. 36 van 49


Bijlage 2 - VIR 2007, Code voor Informatiebeveiliging, Cobit en ITILInleiding RijksoverheidDe Rijksoverheid gebruikt als referentiekader het Voorschrift Informatie Voorziening2007(VIR).In de toelichting op het VIR worden o.a. de volgende punten aangegeven, dieoverheidsdiensten dwingen om aandacht te besteden aan informatiebeveiliging: Het gebruik van computers en datacommunicatie is binnen de rijksdienstgemeengoed geworden. Veel routinematige processen verlopengeautomatiseerd en op praktisch iedere werkplek staat een computer ofterminal. Dat verhoogt de productiviteit van de Rijksdienst. De kwaliteit van debijbehorende werkprocessen wordt steeds meer bepaald door de kwaliteit vande hulpmiddelen die de informatietechnologie biedt. Informatiebeveiliging is een essentieel onderdeel van die kwaliteit. Integriteit,exclusiviteit en beschikbaarheid van informatie en informatiesystemen zijn inhoge mate bepalend voor de kwaliteit van de werkprocessen binnen deRijksdienst. Systemen die alleen financiële gegevens bevatten zijn in de minderheid, veelalzullen in zo'n systeem ook persoonsgegevens zitten of is het systeem van dusdanigbelang dat de beschikbaarheid ervan bijzondere aandacht behoeft. Deverschillende regimes die of uitgaan van het soort gegeven dat beveiligd dientte worden of van de handeling die beschermd dient te worden (denk aanopslag, verwerking en overdracht) overlappen elkaar steeds meer. Het is daaromalleen al vanuit praktisch oogpunt gewenst dat er een kader bestaat voor derijksdienst, waarbinnen systematisch en vergelijkbaar met alle aspecten vaninformatiebeveiliging wordt omgegaan. Zo'n kader is neergelegd in devernieuwde regelgeving voor informatiebeveiliging. De overheid dient op een betrouwbare manier om te gaan met gegevens vanburgers en bedrijfsleven. Ze is daarbij afhankelijk van informatietechnologie. Vooreen deel vloeit de noodzaak tot betrouwbaarheid voort uit wet- en regelgeving.De voortschrijdende ontwikkeling van de informatietechnologie en de inzetdaarvan noodzaken tot voortdurende bezinning. Afwegingen met betrekking totde inzet van informatietechnologie en de organisatie daarvan dienenvastgelegd te worden, ook vanuit de optiek van integriteit, exclusiviteit enbeschikbaarheid. De naleving van beveiligingsmaatregelen die op basis van genoemdeafwegingen plaatsvindt, dient controleerbaar te zijn. Dat is voor de hele overheidals maatschappelijke partij van belang maar zeker ook voor de individueleorganisatie. Bij gebruik van gegevens van derden bijvoorbeeld, dient van hetbegin af aan duidelijk te zijn hoe met vervuiling van die gegevens wordtomgegaan. Informatietechnologie kan de efficiëntie van de rijksdienst verhogenmaar dient niet ten koste te gaan van de positie van de burger. Goedeafspraken bij het koppelen van bestanden zijn daarom nodig.Afstudeerscriptie team <strong>801</strong> blz. 37 van 49


VIR 2007 en beveiligingBij systemen die onderdeel zijn van een keten, maakt het lijnmanagement via eenService Level Agreement (SLA) of een andere vorm van een dienstenovereenkomst,afspraken over de normen waaraan de keten moet voldoen.Daarnaast kan gebruik gemaakt worden van een Third Party Mededeling (TPM)waarin een onafhankelijke partij een verklaring afgeeft over het niveau vanbeveiliging binnen een organisatie.Hiermee wordt een garantie afgegeven dat de andere organisatie in de ketenvoldoet aan een vooraf vastgesteld beveiligingsniveau.Voor de beschikbaarheid van geautomatiseerde of handmatige (papieren archief)informatiesystemen worden tegenwoordig meestal Service Level Agreements (SLA) –of vergelijkbare overeenkomsten met een andere benaming – afgesloten tussen deeigenaar van het informatiesysteem (uiteindelijk lijnmanagement) en de ITdienstenleverancier.Beschikbaarheid is meer en meer het werkterrein van de beheerder en wordt vooralmet techniek gerealiseerd. De beheerder is verantwoordelijk voor het correct enbeheerst uitvoeren van de afspraken uit de SLA en rapporteert hierover aan deopdrachtgever. Voor de informatiebeveiligingsfunctie rest vooral het toezicht op demaatregelen die waarborgen, dat informatie niet verloren gaat, indien zich ernstigeproblemen voordoen.Code voor Informatiebeveiliging BS 7799-1:2000In de CvI wordt alleen gesproken over de contracten die behoren bij outsourcing ende bijbehorende beveiligingseisen:De beveiligingseisen van een organisatie die het beheer van een deel of alleinformatiesystemen, netwerken en/of desktopomgevingen uitbesteedt, dienen ineen contract tussen twee partijen te worden overeengekomen en vastgelegd.Opgenomen zou moeten worden:hoe aan wettelijke eisen wordt voldaan;welke voorzieningen zijn getroffen om bewustwording te waarborgen;hoe de integriteit en vertrouwelijkheid van de kernactiviteiten van degebruikersorganisatie zijn geborgd;welke fysieke en logische beheersmaatregelen m.b.t. gevoelige informatie zijngetroffen;beschikbaarheid van de services in geval van een calamiteit;welke niveaus van fysieke beveiliging worden geleverd;het recht om te auditenAfstudeerscriptie team <strong>801</strong> blz. 38 van 49


ITIL Security ManagementITIL is een publicatie van de “beste praktijkoplossingen” op het gebied van beheervan Informatie Technologie. Het geeft richtlijnen hoe een IT-serviceorganisatie hetbest kan garanderen dat haar klanten de producten en diensten krijgen die zijverlangen. Het doel van ITIL is meer grip te krijgen op de kwaliteit van de ITdienstverlening.Het beoogt een kwaliteitssysteem te zijn voor het beheren van de IT-infrastructuur. ITILbeschrijft processen, die bij een adequate implementatie de kwaliteit van dedienstverlening voor de afnemers zeker stelt.Er moet echter wel aan de volgende randvoorwaarden worden voldaan: omdat ITIL uitsluitend logische procesbeschrijvingen geeft, maar niet ingaat opde aspecten als het beleggen van verantwoordelijkheden en criteria voor deinrichting, stelt dit hoge eisen aan de inrichting van de organisatie en de sizingvan ITIL, om het tot een werkend en vooral werkbare systematiek te vormen; ITIL beperkt zich tot het beschrijven van de beheerprocessen. Uitvoerende ITtakenworden niet beschreven en ook de beheerprocessen aan degebruikerskant komen niet aan de orde.Het basisprincipe van ITIL is, dat de IT service organisaties diensten levert aan deafnemer (gebruikersorganisatie) tegen gerechtvaardigde kosten. ITIL geeft geenharde koppeling tussen de te verlenen diensten en de vergoeding die hiervoorgegeven wordt.Hieronder worden de ITIL-processen genoemd: Strategisch niveau: Management-processen Tactisch niveau: Planning- en sturingsprocessen (service delivery set) Operationeel niveau: Ondersteuningsprocessen (service support set) Operationeel niveau: Operationele beheerprocessenDe tactische processen zorgen in overleg met de klant voor een detaillering vanafspraken en de plannen die nodig zijn voor de IT-dienstverlening. Service levelmanagement is een belangrijk proces op tactisch niveau.Beveiliging en beheerOrganisaties zijn voor het functioneren steeds sterker afhankelijk van IT. Daarommoeten eisen worden gesteld aan informatiebeveiliging. Deze eisen wordenopgelegd aan de aanbieder van IT-diensten. De SLA is hiervoor een goedcommunicatiekanaal. Het ITIL proces Security Management geeft de structureleinpassing van beveiliging in de beheerorganisatie en zorgt ervoor dat dedienstverlening op beveiligingsgebied op het met de klanten afgesproken niveaublijvend worden geboden. Beveiliging en beheer zijn onafscheidbaar. Zonder eengoed ingericht beheer is beveiliging niet mogelijk en vice versa.Het ITIL Security Management is mede gebaseerd op de Code voorInformatiebeveiliging.Afstudeerscriptie team <strong>801</strong> blz. 39 van 49


In ITIL wordt het perspectief gekozen van de IT-serviceorganisaties. Het doel van hetproces Security Management is tweeledig:1) het realiseren van de beveiligingseisen in de (verschillende) SLA’s en andereexterne vereisten in andere contracten, wetgeving en eventueel intern of externopgelegd beleid.2) Het realiseren van een basisniveau aan beveiliging. Dit is nodig om de eigencontinuïteit van de beheerorganisatie te waarborgen, maar ook om te komen toteen vereenvoudiging van het SLM voor informatiebeveiliging. Het beheer vaneen groot aantal verschillende SLA’s is complexer dan een beperkt aantal.Het proces Security Management heeft relaties met de meeste andere ITILprocessen.In de andere processen moeten namelijk activiteiten plaatsvinden tenbehoeve van beveiliging.De ITIL processen zijn tot op zekere hoogte toe te wijzen aan de drie besturingslagendie in organisaties kunnen worden herkend. In de bovenste laag wordt de strategievan het beheer uitgestippeld. Voor informatiebeveiliging is deze vooral van belangwaar het de organisatie van de beheerorganisatie betreft. De middelste laag(tactiek) bevinden zich de Service Delivery processen. Deze processen zorgen voorhet opstellen van SLA’s en die de dienstverlening verzorgen conform de afspraken indeze SLA’s. De beveiligingsafspraken worden ook in de SLA’s vastgelegd. Het procesSecurity Management bevindt zich ook in deze laag. Dit proces heeft relaties met deandere Service Delivery processen: Service Level Management; Availability Management; Capacity Management; Business Continuity Planning; Financial Management for IT.Tenslotte is er dan nog de onderste laag, de operationele laag. In deze laag zijn deService Support processen te vinden. De Service Support processen verzorgen hetdaadwerkelijk operationeel beheer van IT-middelen zelf. Het proces SecurityManagement is afhankelijk van deze processen omdat dezevoorwaardenscheppend zijn.In de SLA worden afspraken tussen de IT-serviceorganisatie en degebruikersorganisatie vastgelegd.De SLA is de verantwoordelijkheid van het Service Level Management en fungeertals belangrijkste sturingsinformatie voor de ITIL-processen.Beveiligingsparagraaf in de SLADe totstandkoming van de beveiligingsparagraaf in de SLA begint bij debeveiligingsbehoefte van de klant. De klant geeft uitdrukking aan de belangen vanzijn bedrijfsprocessen. Deze bedrijfsprocessen zijn afhankelijk van IT en daarom vande IT-beheerorganisatie. Hoe de beveiligingsbehoefte moet worden bepaald vormtgeen onderdeel van ITIL. Doorgaans wordt gebruik gemaakt van een risicoanalyse.Uit deze analyse komen dan de service level requirements voor beveiliging.De vertegenwoordiger van de gebruikersorganisatie en de accountmanager vande IT-serviceorganisatie treden hierover in onderhandeling. De IT-serviceorganisatielegt zijn standaard aanbod (vastgelegd in een Service Catalogus) naast de door deklant gedefinieerde service level requirements. In de Service Catalogus is hetbasisniveau van beveiliging ofwel security baseline weergegeven.Afstudeerscriptie team <strong>801</strong> blz. 40 van 49


De klant en de accountmanager stellen samen vast hoe de service levelrequirements en de service catalogus op elkaar passen.Relatie Security Management met Service Level Management.SLM zorgt ervoor dat afspraken worden vastgelegd en nagekomen over de dienstendie aan gebruikersorganisaties (klanten) worden geleverd. Het doel is te komen toteen optimaal niveau van IT-dienstverlening. SLM onderscheidt een aantalsamenhangende beveiligingsactiviteiten waarin Security Management eenbelangrijke rol speelt: identificatie van de beveiligingsbehoefte van de klant (het vaststellen van debeveiligingsbehoefte blijft de verantwoordelijkheid van de klant zelf omdat dezebehoefte voortkomt uit zijn bedrijfsbelangen); verifiëren van de haalbaarheid van deze beveiligingsbehoefte van de klant; voorstellen doen voor, onderhandelen over en vastleggen van het gewenstebeveiligingsniveau van de IT-diensten in de SLA; doen bepalen, opstellen en vastleggen van interne beveiligingsnormen voor deIT-dienstverlening; doen bewaken van die beveiligingsnormen; rapporteren over geleverde IT-diensten.Voor de eerste drie activiteiten levert Security Management input en ondersteuningaan SLM. Activiteiten vier en vijf worden uitgevoerd door Security Management.Voor activiteit zes levert onder andere Security Management input. Dedaadwerkelijke uitvoering van de werkzaamheden is een kwestie van overleg tussende SLM en de SM.Afstudeerscriptie team <strong>801</strong> blz. 41 van 49


Bijlage 3 - gehanteerde gestructureerde vragenlijstDe interviewvragen zijn ingedeeld in drie onderdelen, te weten:- algemene vragen ter introductie- vragen m.b.t. procesgang (lifecycle)- vragen m.b.t. procesrollen- vragen m.b.t. inhoud (elementen in de SLA)• Algemeen (vooraf te sturen)1. Bij welk organisatieonderdeel bent u werkzaam?2. Wat is uw functie en kunt u een korte beschrijving geven van uwwerkzaamheden?3. Hoe zou u de organisatiecultuur typeren? (denk aan bureaucratisch of informeel,wordt er aan regels gehecht en wordt de naleving gemonitord)• Algemeen (interview)4. Wat verstaat u onder een SLA?5. Wat is het doel van het opstellen van een SLA?6. Is het doel van een SLA ook ergens vastgelegd binnen de organisatie?• Procesgang (lifecycle SLA)a) Aanleiding totstandkoming SLA (interview)7. In welke situaties wordt in uw organisatie een SLA opgesteld?8. Welke risico’s wilt u afdekken met een SLA?b) Ontwikkelen (opstellen)9. Hoe gaat de voorbereiding en informatieverzameling ten behoeve van hetopstellen van een SLA?10. Hoe wordt een team samengesteld?11. Maakt u gebruik van een standaard SLA of wordt deze iedere keer opnieuwopgesteld?12. Welk normenkader/referentiekader wordt gehanteerd bij het opstellen van eenSLA?13. Waarom wordt dat specifieke normenkader/referentiekader gebruikt?14. Hoe komt de inhoud van de overeenkomst tot stand? (zie bijlage 1 metstandaard onderwerpen SLA)15. Waarom zijn juist de genoemde elementen in de SLA opgenomen en geenandere elementen?16. Zijn er ontbrekende elementen welke nog zouden moeten worden toegevoegd?(bijv. calamiteitenplan)17. Hoe lang duurt de totstandkoming van een gemiddeld SLA? (doorlooptijdproces)18. Wat is de werkelijke tijdsbesteding bij de totstandkoming geweest? (feitelijketijdsbesteding bijv in uren/dagen)19. Welke afspraken worden gemaakt m.b.t. het beheer van de SLA; evaluatie vanSLA en tijdstippen voor herziening? (alleen stellen als er niets over is opgenomenin de SLA)Afstudeerscriptie team <strong>801</strong> blz. 42 van 49


c) Testen (interpretatie door verschillende partijen)20. Wordt een concept SLA voorgelegd bij de betrokken partijen voordat deze<strong>definitief</strong> gemaakt wordt?21. Welke criteria worden gehanteerd bij het ‘testen’?22. Wordt er met de verschillende partijen gesproken over de inhoud van hetconcept SLA?d) Gebruik van de SLA23. Hoe lang wordt er binnen uw organisatie gewerkt met SLA’s?24. Is een SLA een levend document binnen uw organisatie?25. Wordt er gewerkt aan het belang van de SLA en de bewustwording daarvan bijde gebruikers? Zo ja, op welke wijze?26. Worden sancties toegepast bij het niet nakomen van de overeengekomenafspraken?27. Wat zijn de sterke en zwakke punten van het gebruik van een SLA?e) Evaluatie werking SLA en eventueel herziening28. Hoe vaak wordt gerapporteerd over de werking van de SLA?29. Hoe vaak vind er overleg plaats n.a.v. bovengenoemde rapportages?30. Welke functionarissen zijn betrokken bij de evaluatie?31. Op welke wijze worden eventuele wijzigingen n.a.v. de evaluatie doorgevoerd?32. Hoe vind verlenging of hernieuwing van een SLA plaats?f) SLA niet meer in gebruik33. Hoe vindt de beëindiging plaats?34. Wie neemt de beslissing(en) daarover?• Procesrollen35. Welke rollen onderscheidt u in de verschillende fasen van de lifecycle van eenSLA?36. Hoe zijn deze rollen te typeren? (kaderstellend of adviserend)37. Hoe zijn de rollen organisatorisch belegd? (welke functies of afdelingen,competenties)38. Op welk functieniveau (bij wie) is de verantwoordelijkheid voor de werking vande SLA belegd?39. Is dit functieniveau bepalend of controlerend of adviserend?40. Worden bevoegdheden en verantwoordelijkheden gemandateerd ofgedelegeerd?41. Door wie worden de go/no go beslissingen genomen in hettotstandkomingsproces van een SLA?42. Wie accordeert de opgenomen elementen in de SLA? (vanuit welke rol)43. Worden bij iedere SLA dezelfde functionarissen betrokken?44. Wie bewaakt de afspraken zoals vastgelegd in de SLA?45. Wordt er gebruik gemaakt van experts? (bijvoorbeeld een IT-auditor, jurist,gebruikers)Afstudeerscriptie team <strong>801</strong> blz. 43 van 49


Inhoud specifiek m.b.t. beveiliging46. Wat verstaat u onder de beveiliging?47. Wat zijn de belangrijkste aandachtspunten m.b.t. beveiliging? (sleutelfactoren,risico’s)48. Hoe is men tot de invulling gekomen van het element beveiliging in een SLA?49. Welke functionarissen zijn betrokken bij de invulling van beveiliging?50. Welke rechten en plichten worden vastgelegd en waarom?51. Hoeveel beveiligingsincidenten heeft u (bijv. per jaar?)52. Wat is de aard van de incidenten?53. Zijn eventuele fouten toe te wijzen aan bepaalde functionarissen?54. Zijn er specifieke sancties op beveiligingsgebied? Is dit wel of niet wenselijk?55. Waarom staan sommige/alle beveiligingsaspecten niet expliciet in de SLA? (nadit gecheckt te hebben in de SLA)• Afsluiting56. Heeft u nog aanvullende op- of aanmerkingen?Afstudeerscriptie team <strong>801</strong> blz. 44 van 49


Bijlage 4 - het AuditinstrumentOnderstaand is het instrument weergegeven dat is besproken in hoofdstuk 4 van descriptie. Als inleiding hierop zal een korte gebruikshandleiding worden beschreven.GebruikershandleidingOm aan de slag te gaan met het instrument moeten allereerst afspraken gemaaktworden met de juiste personen van de gebruikersorganisatie en de juiste personenvan de IT-serviceorganisatie. Het is zinvol de relevante informatie en documentatieop te vragen en door te nemen voordat de interviews plaatsvinden. De opgenomenvragen in de tabel en de aanvullende vragen onder de tabel dienen als leidraadvoor de interviews.AuditinstrumentHoofdcategorie Subcategorie Aandachtspunten inclusief te stellen vragen AntwoordDoelenIs het doel van de SLA bekend bij de J/NAlgemeenbetrokken partijen?Randvoorwaarden enuitgangspuntenZijn er uitgangspunten en randvoorwaardenopgenomen in de SLA?J/NRechten en plichtenZijn de rechten en plichten van zowel degebruikersorganisatie als de ITserviceorganisatiein de SLA opgenomen?J/NLifecycle SLAAanleidingtotstandkoming SLAIs er nagedacht over de risico’s die met deSLA moeten worden gemitigeerd?J/NOntwikkelenIs er voor de totstandkoming van de SLAeen team samengesteld?J/NTestenIs er een testprocedure – vóóringebruikname van de SLA – beschreven?J/NGebruik van de SLAIs de SLA door beide partijen ondertekend?Is de SLA een “levend document” voorbeide betrokken partijen?Zijn er sancties opgenomen in de SLA?J/NJ/NJ/NEvaluatie van de SLAWordt er gerapporteerd over de realisatievan de overeengekomen afspraken in deSLA?Vinden er gesprekken plaats naaraanleiding van de rapportages?Worden er ook wijzigingen doorgevoerd inde afspraken?J/NJ/NJ/NInhoud van eenSLA (algemeen)BedrijfsdoelstellingenIs er in de SLA een relatie gelegd met debedrijfsdoelstellingen van degebruikersorganisatie?J/NSamenstellen SLAIs er voor het opstellen van een SLA eentemplate gebruikt?Is geborgd dat alle relevanteafspraken/servicelevels zijn opgenomen inde SLA?J/NJ/NKwaliteitsniveauZijn alle afspraken/servicelevels in de SLAconcreet en meetbaar?J/NAfstudeerscriptie team <strong>801</strong> blz. 45 van 49


Inhoud van eenSLA (beveiliging)Begrip ‘Beveiliging’Is het begrip beveiliging in de SLAbeschreven?Is het begrip voor beide partijen helder?Zijn de rechten en plichten van beidepartijen m.b.t. beveiliging opgenomen?J/NJ/NJ/NReferentiekadersIs gebruik gemaakt van een algemeenaanvaard normenkader voor het opstellenvan de SLA?Zijn er afspraken gemaakt over het tehanteren normenkaderinformatiebeveiliging?Zijn er afspraken gemaakt over deaantoonbare naleving van datnormenkader (TPM)?J/NJ/NJ/NRegelgevingIs er rekening gehouden met de geldenderegelgeving betreffende het onderwerpbeveiliging (VIR)?J/NIncidentenZijn er afspraken in de SLA vastgelegd overhoe om te gaan metbeveiligingsincidenten?J/NAfstudeerscriptie team <strong>801</strong> blz. 46 van 49


Vragenlijst ter verdieping en/of aanvulling van de bovengenoemde onderwerpenHieronder zijn de aanvullende vragen opgenomen. De indeling komt overeen metde in de tabel opgenomen onderwerpen.Achter sommige vragen is tussen haakjes een verwijzing opgenomen naar hetcorresponderende nummer van een vraag uit de door ons gehanteerde vragenlijstin het onderzoek.DoelenEen SLA is bedoeld als overeenkomst tussen twee partijen.1) Kunt u verwoorden en toelichten wat een SLA in uw organisatie betekent? (nr. 4)De doelstelling van een SLA behoort transparant te zijn.2) Wat is volgens u het doel van een SLA voor uw organisatie? (nr. 5&6)3) Is het doel van het opstellen voor beide partijen duidelijk? (nr. 5&6)Randvoorwaarden en uitgangspuntenEen SLA behoort een levend document te zijn.4) Wordt het belang van een SLA in uw organisatie onderkend? (nr. 24)5) Waaruit blijkt dit? (nr. 25)Een SLA dient een beperkte geldigheidsduur te hebben.6) Welke looptijd is vastgelegd voor de betreffende SLA? (nr. 33&34)Rechten en plichtenRechten en plichten zijn onlosmakelijk verbonden aan de levering van diensten doorde ene partij aan de andere7) Welke rechten en plichten zijn van belang om in de SLA te worden opgenomen?8) Op welke wijze worden de rechten en plichten geregeld, als ze niet zijnopgenomen in de SLA?Aanleiding totstandkoming SLAEen SLA is een middel om afspraken tussen twee partijen vast te leggen.9) Wordt bij elke dienst die wordt uitbesteedt een SLA opgesteld? (nr. 7)10) In welke situatie wordt er wel en in welke situatie wordt er geen SLA opgesteld?(nr. 7)11) Welke risico’s wil uw organisatie met een SLA afdekken? (nr. 8)OntwikkelenHet opstellen van een SLA vereist het samenstellen van een team waarin de juistepersonen met elkaar om de tafel zitten.12) Indien er geen team is samengesteld, waarom niet? (nr. 10)13) Zijn de belanghebbenden van de IT-dienstverlening vanuit degebruikersorganisatie en IT-serviceorganisatie wel betrokken bij de totstandkomingvan de SLA?In een SLA dienen de overeengekomen afspraken concreet en meetbaar te zijn.14) Zijn de afspraken eenduidig, ondubbelzinnig en meetbaar vastgelegd?15) Welke voorbeelden zijn daarvan terug te vinden in de SLA?Afstudeerscriptie team <strong>801</strong> blz. 47 van 49


Samenstellen SLAHet gebruik maken van een standaard sjabloon als uitgangspunt kan voorkomendat relevante onderwerpen worden vergeten.16) Indien er geen gebruik wordt gemaakt van een standaard, hoe worden dan deonderwerpen bepaald die worden opgenomen in de SLA?17) Hoe wordt de volledigheid van de minimaal vast te leggen onderdelengewaarborgd?TestenDe interpretatie van afspraken in de ‘definitieve’ SLA dient voor beide partijen gelijkte zijn.18) Worden conceptversies van SLA’s uitgewisseld tussen beide partijen? (nr. 20)19) Bestaan er testcriteria voor de beoordeling van het gewenste kwaliteitsniveauvan een SLA? (nr. 21)20) Wat zijn de gehanteerde testcriteria? (nr. 21)Gebruik van de SLAEen SLA dient door beide partijen te worden goedgekeurd en ondertekend.21) Indien de SLA niet door de betrokken partijen is ondertekend, waarom is dit niethet geval?22) Welke functionarissen zouden moeten ondertekenen?Een SLA dient een ‘levend’ document te zijn.23) Wordt er gewerkt aan de bewustwording van de SLA bij de gebruikers? (nr. 25)24) Zo ja, op welke wijze? (nr. 25)Sancties kunnen een hulpmiddel zijn om druk uit te oefenen op het nakomen vanovereengekomen afspraken.25) Indien er geen sancties zijn opgenomen in de SLA, waarom is dit niet gebeurd?26) Indien er wel sancties zijn opgenomen in de SLA, wat voor soort sancties betrefthet?27) Zijn de eventuele sancties goed toepasbaar?Evaluatie van de SLAPeriodieke evaluaties zijn nodig om vast te stellen of een SLA ook werkt zoals isbedoeld.28) Is vastgelegd hoe vaak er gerapporteerd moet worden over de werking van deSLA? (nr. 28)29) Vindt er daadwerkelijk overleg plaats tussen de gebruikersorganisatie en ITserviceorganisatieover de geleverde rapportages? (nr. 29)30) Welke functionarissen zijn betrokken bij de evaluatie? (nr. 30)BedrijfsdoelstellingenDe bedrijfsdoelstellingen zijn in hoge mate bepalend voor de concrete uitwerkingervan in een SLA.31) Indien de relatie met de bedrijfsdoelstellingen niet in één oogopslag zichtbaar is,kunt u dan aangeven waar ze terug zijn te vinden in onderdelen van de SLA?KwaliteitsniveauOm een zeker kwaliteitsniveau te kunnen behalen, is het van belang dat afsprakenen serviceniveaus meetbaar zijn gemaakt.Afstudeerscriptie team <strong>801</strong> blz. 48 van 49


32) Als er geen concrete vertaling is gemaakt naar meetbare eenheden, hoe wordtdan vastgesteld of de afspraken naar behoren zijn nagekomen?Beveiliging en SLAInformatiebeveiliging is een belangrijk onderdeel van de afspraken en dus ook vande SLA.33) Wat wordt binnen de organisatie verstaan onder het begrip ‘beveiliging’? (nr. 46)34) Wat zijn de belangrijkste aandachtspunten als het om beveiliging gaat? (nr. 47)35) Welke functionarissen zijn betrokken bij de invulling van het onderwerpbeveiliging in een SLA? (nr. 49)36) Waarom zijn de rechten en plichten m.b.t. beveiliging niet vastgelegd in de SLA?37) Op welke wijze wordt er dan wel invulling gegeven aan debeveiligingsparagraaf?ReferentiekadersReferentiekaders zijn zeer bruikbare hulpmiddelen bij het opstellen van een SLA38) Indien geen gebruik wordt gemaakt van algemeen aanvaarde kaders, aanwelke richtlijnen worden dan gerefereerd?RegelgevingNaast verplichte regelgeving kunnen er ook bedrijfsinterne richtlijnen zijn opgesteldwaarin het onderwerp beveiliging is opgenomen.39) Voorzien de interne richtlijnen wel in het afdekken van beveiligingsrisico’s?IncidentenDe wijze waarop wordt omgegaan met beveiligingsincidenten zegt iets over derisico’s die worden gelopen en de mate waarin de getroffen maatregelen effectiefzijn.40) Wordt er gerapporteerd over incidenten? (nr. 51&52&53)41) Indien er wordt gerapporteerd, aan wie en op welke termijn? (nr. 49)42) Zijn er specifieke sancties van kracht op beveiligingsgebied? (nr. 54)Afstudeerscriptie team <strong>801</strong> blz. 49 van 49

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!