‘Toetsingskader voor IV-dienstverlening binnen de ... · ‘Toetsingskader voor...

of 49 /49
‘Toetsingskader voor IV-dienstverlening binnen de Rijksoverheid’ - nut en noodzaak van een SLA - postgraduate IT-opleiding Vrije Universiteit Amsterdam Ilse van der Heijden - 9981255 Frank Sluijter - 9981234 - 801 - Den Haag, maart 2008

Embed Size (px)

Transcript of ‘Toetsingskader voor IV-dienstverlening binnen de ... · ‘Toetsingskader voor...

  • Toetsingskader voor IV-dienstverlening binnen

    de Rijksoverheid

    - nut en noodzaak van een SLA -

    postgraduate IT-opleiding Vrije Universiteit Amsterdam

    Ilse van der Heijden - 9981255

    Frank Sluijter - 9981234

    - 801 -

    Den Haag, maart 2008

  • Afstudeerscriptie team 801 blz. 2 van 49

    Colofon

    Toetsingskader voor IV-dienstverlening binnen de Rijksoverheid Het doel van dit onderzoek is te komen tot een auditinstrument dat gebruikt kan worden binnen de Rijksoverheid bij de totstandkoming of de beoordeling van een SLA. Scriptie

    Deze scriptie is geschreven in het kader van de afronding van de postgraduate IT-auditopleiding aan de Vrije Universiteit van Amsterdam. Begeleider Vrije Universiteit Dr. P.H.A.M. Frijns Begeleider EDP Auditpool

    Dhr. E. Pothast RE

    Begeleider Belastingdienst

    Dhr. B. Bokhorst RA RE Auteurs

    Mw. I. van der Heijden Ir. W.F.Th. Sluijter mba

  • Afstudeerscriptie team 801 blz. 3 van 49

    Voorwoord

    Voor u ligt onze afstudeerscriptie ter afronding van de postgraduate IT-audit-opleiding aan de Vrije Universiteit van Amsterdam. Deze scriptie is het resultaat van een leerzaam, interessant en soms tijdrovend traject, uitgevoerd van mei 2007 tot en met maart 2008. Het opdoen van inzicht voor wat betreft theorie en praktijk rondom het werken met Service Level Agreements is voor ons een belangrijk persoonlijk resultaat van het onderzoek. Met deze scriptie hebben we daarnaast een bijdrage geleverd aan de kennis met betrekking tot dit onderwerp. Op deze plaats willen we graag onze begeleidend VU-docent Pieter Frijns, bedanken voor zijn op- en aanmerkingen, aanbevelingen en aanmoedigingen tijdens het scriptietraject. Daarnaast willen we ook onze bedrijfscoaches van de Belastingdienst, Bart Bokhorst en Erik Pothast van de EDP Auditpool bedanken voor hun inzet en het geven van adviezen en feedback op de conceptversies van deze scriptie. Tenslotte willen we onze partners, collegas en vrienden bedanken voor de ondersteuning en support tijdens de studie en bij het schrijven van deze scriptie. Den Haag/Utrecht, maart 2008 Ilse van der Heijden en Frank Sluijter

  • Afstudeerscriptie team 801 blz. 4 van 49

    Samenvatting

    Deze scriptie vormt het eindresultaat van de IT-auditorsopleiding aan de Vrije Universiteit te Amsterdam. In de afgelopen decennia is er toenemende aandacht voor de beschikbaarheid en het verstrekken van informatie. Dit uit zich in de toenemende communicatie tussen enerzijds de Rijksoverheid en anderzijds de burgers en het bedrijfsleven. De beschikbaarheid, integriteit en vertrouwelijkheid van informatie moet hierbij voldoende geborgd zijn. Daarnaast moet voorkomen worden dat onjuiste informatie wordt verschaft, maar ook dat informatie wordt verstrekt aan ongeautoriseerde personen en bedrijven. De consequentie hiervan is dat meer aandacht wordt besteed aan de informatiebeveiliging. De informatievoorziening steunt voor een groot deel op IT en dit wordt alleen maar meer. Door een toename van het gebruik van IT voor IV-dienstverlening worden de kwetsbaarheden groter. Binnen de Rijksoverheid vormt IT geen core business en wordt daarom steeds vaker uitbesteed aan daartoe gespecialiseerde dienstverleners. De uitbestedende Rijksoverheid blijft daarbij verantwoordelijk voor de uitbestede diensten en stelt kwaliteitseisen aan die dienstverlening. Daarom moeten duidelijke afspraken worden gemaakt. Deze worden vastgelegd in zogeheten Service Level Agreements (SLAs). Meestal wordt daarin het begrip beschikbaarheid concreet uitgewerkt. De twee andere aspecten van informatiebeveiliging (integriteit en vertrouwelijkheid) worden minder belicht. Daarom is de volgende vraagstelling geformuleerd:

    Op welke wijze kan worden getoetst of aan de eisen wordt voldaan die aan een

    Service Level Agreement (SLA) worden gesteld om de afstemming tussen de

    gebruikersorganisatie en de IT-serviceorganisatie binnen de Rijksoverheid vast te

    leggen, waarbij ook de noodzakelijke informatiebeveiliging in opzet, bestaan en

    werking in de IV-dienstverleningsketen is geborgd?

    Het onderzoek is uitgevoerd in twee delen, te weten: literatuur- en praktijkonderzoek. Voor het praktijkonderzoek zijn interviews gehouden aan de hand van een gestructureerde vragenlijst die voortgekomen is uit literatuurstudie. Het doel van het onderzoek is een auditinstrument te ontwikkelen dat gebruikt kan worden door een auditor bij de beoordeling van SLAs of door een adviseur die gevraagd is de totstandkoming van een SLA te begeleiden. Met dit auditinstrument wordt een handreiking geboden om te toetsen of aan de eisen wordt voldaan die aan een SLA wordt gesteld. Het is gelukt om dit auditinstrument te ontwikkelen. De vragen, opgenomen in het instrument, kunnen worden gebruikt om de onderzoeksvraag te beantwoorden. Een aanbeveling is om het instrument door middel van vervolgonderzoek te valideren. Daarnaast kan geconcludeerd worden dat de normenkaders informatiebeveiliging niet in de SLAs worden benoemd en er geen accountantsverklaringen (TPM) over de naleving ervan zijn aangetroffen. Dat is opvallend en verdient aandacht. Het bevreemd ook, omdat het concreet in de regelgeving (bijv. toelichting VIR en de Code voor Informatiebeveiliging) wordt genoemd.

  • Afstudeerscriptie team 801 blz. 5 van 49

    Inhoudsopgave

    Colofon ________________________________________________________________________ 2

    Voorwoord _____________________________________________________________________ 3

    Samenvatting __________________________________________________________________ 4

    1 Inleiding en onderzoeksopzet__________________________________________________ 6

    1.1 Inleiding __________________________________________________________________________ 6

    1.2 Aanleiding voor het onderzoek ____________________________________________________ 6

    2 Theoretisch kader SLAs en beveiliging in een overheidsomgeving______________ 11

    2.1 Inleiding _________________________________________________________________________ 11

    2.2 Relatie tussen de gebruikersorganisatie en IT-serviceorganisatie _____________________ 11 2.2.1 Kenmerken/typering van de gebruikersorganisatie 12 2.2.2 Kenmerken/typering van de IT-serviceorganisatie 13 2.2.3 Verschillen tussen de gebruikers- en IT-serviceorganisatie 13

    2.3 Wat is de definitie van een Service Level Agreement?______________________________ 13

    2.4 Welke soorten Service Level Agreements zijn te onderkennen?______________________ 14

    2.5 Wat is het doel van het opstellen van een Service Level Agreement? _______________ 16

    2.6 Hoe komt een Service Level Agreement idealiter tot stand? ________________________ 16

    2.7 Wat houdt beveiliging in vanuit IV-dienstverleningsperspectief? _____________________ 18

    3 Uitkomsten praktijkonderzoek ________________________________________________ 20

    3.1 Inleiding _________________________________________________________________________ 20

    3.2 Algemeen _______________________________________________________________________ 20

    3.3 Lifecycle van een SLA ____________________________________________________________ 21

    3.4 Inhoud van een SLA (algemeen) __________________________________________________ 23

    3.5 Inhoud van een SLA (beveiliging) _________________________________________________ 24

    4 Het auditinstrument __________________________________________________________ 25

    4.1 Inleiding _________________________________________________________________________ 25

    4.2 Het instrument ___________________________________________________________________ 25

    5 Conclusies en aanbevelingen ________________________________________________ 28

    6 Reflectie_____________________________________________________________________ 29

    Literatuurlijst ___________________________________________________________________ 30

    Bijlagen _______________________________________________________________________ 31

    Bijlage 1 - aspecten van een SLA _____________________________________________________ 31

    Bijlage 2 - VIR 2007, Code voor Informatiebeveiliging, Cobit en ITIL______________________ 37

    Bijlage 3 - gehanteerde gestructureerde vragenlijst ____________________________________ 42

    Bijlage 4 - het Auditinstrument ________________________________________________________ 45

  • Afstudeerscriptie team 801 blz. 6 van 49

    1 Inleiding en onderzoeksopzet

    1.1 Inleiding Dit hoofdstuk gaat in op de aanleiding voor het onderzoek en de onderzoeksaanpak. 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.4 beschrijft het resultaat van het onderzoek en tot slot wordt in paragraaf 1.5 de indeling van deze scriptie toegelicht. 1.2 Aanleiding voor het onderzoek

    In de afgelopen decennia is er toenemende aandacht voor de beschikbaarheid en het verstrekken van informatie. Dit uit zich ook in de toenemende communicatie tussen enerzijds de Rijksoverheid en anderzijds de burgers en het bedrijfsleven. De integriteit van informatie moet hierbij voldoende geborgd zijn. Daarnaast is het van belang dat geen verkeerde informatie wordt uitgewisseld en dat wordt voorkomen dat informatie terechtkomt bij niet geautoriseerde personen. De consequentie hiervan 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 deel op IT. Binnen de Rijksoverheid vormt IT geen core business en wordt daarom vaak uitbesteed aan daartoe gespecialiseerde dienstverleners. Daarbij stelt de Rijksoverheid kwaliteitseisen aan die uitbestede dienstverlening. Vanuit het perspectief van IV-dienstverlening - het totaal van ontwikkeling, onderhoud, beheer en exploitatie van de IV-infrastructuur - wordt onderscheid gemaakt tussen een gebruikersorganisatie en een IT-serviceorganisatie. Onder IT-serviceorganisatie wordt de eerder genoemde gespecialiseerde dienstverlener bedoeld. De gebruikersorganisatie en de IT-serviceorganisatie stemmen vraag en aanbod af en maken vervolgens afspraken over de te leveren diensten door de IT-service-organisatie. Een Service Level Agreement is een middel om deze afspraken vast te leggen.

  • Afstudeerscriptie team 801 blz. 7 van 49

    De relatie tussen de gebruikersorganisatie en de IT-serviceorganisatie wordt als volgt gevisualiseerd:

    Gebruikersorganisatie IT-serviceorganisatie Externe leverancier

    Figuur 1: relatie tussen gebruikersorganisatie en IT-serviceorganisatie

    (Bron: figuur is afgeleid van de presentatie trappetjesmodel als opstap naar een dienstverleningsmodel van Dr. P.H.A.M. Frijns, Apeldoorn, sept. 2007)

    1.3 Onderzoeksvragen De doelstelling van deze scriptie1 is het ontwerpen van een instrument dat gebruikt kan worden binnen de Rijksoverheid bij de totstandkoming van een SLA of bij de beoordeling van een gerealiseerde SLA, waarbij het onderwerp informatiebeveiliging voldoende wordt belicht. Het instrument kan door de IT-auditor, maar ook door een adviseur gebruikt worden die wordt gevraagd het proces 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 een

    Service Level Agreement (SLA) worden gesteld, om de afstemming tussen de

    gebruikersorganisatie en de IT-serviceorganisatie binnen de Rijksoverheid vast te

    leggen, waarbij ook de noodzakelijke informatiebeveiliging in opzet, bestaan en

    werking in de IV-dienstverleningsketen is geborgd?

    De belangrijkste elementen uit de centrale onderzoeksvraag 2 zijn onderstreept. Om de centrale onderzoeksvraag te kunnen beantwoorden zijn de volgende deelvragen 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)

    Under-pinning contract

    (UC)

    Leveran-cier: A B C

    Wederzijdse

    afstemming

    Behoeften

    Opera-tional Level Agree-ment (OLA)

    Kaders

    Randvoorwaarden

    Diensten

  • Afstudeerscriptie team 801 blz. 8 van 49

    Deelvragen:

    Gebruikersorganisatie en IT-serviceorganisatie 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?

    Service Level Agreement 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? Informatiebeveiliging 8. Wat houdt beveiliging in vanuit IV-dienstverleningsperspectief? Auditinstrument 9. Waaraan moet een Service Level Agreement voldoen? 10. Waaraan moet het proces van totstandkoming en gebruik van een Service Level

    Agreement voldoen? 11. Hoe kan getoetst worden of in de Service Level Agreement de essentile

    onderwerpen zijn benoemd? 1.4 Resultaat van het onderzoek Het resultaat van het onderzoek is een auditinstrument waarin de te stellen eisen aan een SLA en de totstandkoming daarvan zijn opgenomen. Het gaat om een algemeen instrument met eisen/vragen die door de organisaties kunnen worden gesteld om op een goede wijze invulling te geven aan de samenwerking. Deze eisen/vragen dragen bij aan het optimaliseren van de afstemming tussen de gebruikersorganisatie en IT-serviceorganisatie. Dit instrument is zowel toepasbaar voor de auditor als voor de adviseur die gevraagd wordt het totstandkomingsproces van een SLA te begeleiden. 1.5 Onderzoeksaanpak

    Fasering

    De 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 801 blz. 9 van 49

    Onderzoeksmethoden

    De 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 en definities van begrippen. Het literatuuronderzoek is uitgevoerd om het totstandkomingsproces van een SLA te kunnen begrijpen en de antwoorden te krijgen op de deelvragen 1 tot en met 8. Hierbij is onder andere gebruik gemaakt van boeken, (vak)literatuur en internet. Het resultaat van de uitgevoerde deskresearch is opgenomen in hoofdstuk 2. Praktijkonderzoek

    Na 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 niet met naam en toenaam genoemd om redenen van privacy. Het praktijkonderzoek is uitgevoerd door het verzamelen van relevante documentatie ten aanzien van de casus en het houden van interviews bij de betrokken gebruikersorganisatie en twee IT-serviceorganisaties. Het doel van de interviews is: Vaststellen of er naast de elementen genoemd in de literatuur nog elementen

    vanuit 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 interviews

    Op 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 open vragen die niet van tevoren naar de te interviewen personen zijn gestuurd. De duur van de gesprekken is ca.1,5 uur geweest en ze zijn uitgewerkt in een gespreksverslag. Ten behoeve van het onderzoek is een aantal medewerkers genterviewd. Het gaat om de volgende functionarissen: Service Level Managers, Beveiligingsambtenaar, Hoofd IT-projecten, medewerker Portfolio Management en een Algemeen Projectmanager. De uitwerking is in alle gevallen teruggekoppeld naar de genterviewde ter becommentariring. De definitieve versies zijn gebruikt in het onderzoek.

    Resultaat

    De definitieve interviewverslagen en het theoretische kader zijn geanalyseerd. De resultaten hiervan zijn weergegeven in hoofdstuk 3 en 4.

    3 D.B. van Baarda c.s. - Basisboek Methoden en Technieken (2002)

  • Afstudeerscriptie team 801 blz. 10 van 49

    1.6 Leeswijzer scriptie

    De opbouw van deze scriptie is in onderstaande figuur weergegeven: Theorie Praktijk

    Figuur 2: opbouw scriptie

    In hoofdstuk 2 wordt ingegaan op de theorie ten aanzien van de elementen uit de centrale onderzoeksvraag: de SLA, de gebruikers- en IT-serviceorganisatie en informatiebeveiliging. Hoofdstuk 3 geeft de resultaten van de gestructureerde interviews; daarbij wordt een aantal conclusies getrokken. In hoofdstuk 4 wordt het instrument beschreven dat is voortgekomen uit de bevindingen van hoofdstuk 2 en 3. Een overzicht met de daaruit voortgekomen elementen van een SLA die voor een auditor of adviseur van belang zijn, is opgenomen. De conclusie en aanbevelingen ten aanzien van de centrale onderzoeksvraag zijn uitgewerkt in hoofdstuk 5. Hoofdstuk 6 geeft een kort expos van onze eigen bevindingen gedurende het onderzoek.

    H2 Theoretisch kader SLAs

    en beveiliging in een overheidsomgeving

    H3 Bevindingen praktijkonderzoek

    H4 Auditinstrument

    H5 Conclusies en aanbevelingen

    H6 Reflectie

  • Afstudeerscriptie team 801 blz. 11 van 49

    2 Theoretisch kader SLAs en beveiliging in een overheidsomgeving

    2.1 Inleiding Dit theoretische hoofdstuk is gebaseerd op de elementen uit de centrale onderzoeksvraag 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-serviceorganisatie

    De laatste jaren is een sterke toename te zien van uitbesteding van IT. Een belangrijk argument daarvoor is dat gebruikersorganisaties zich willen richten op de kernactiviteiten en geen hinder willen hebben van allerlei IT-vraagstukken: het moet gewoon de bedrijfsvoering ondersteunen. Hierdoor wordt de behoefte vergroot om het beheer van de IT-infrastructuur, of het beheer van applicaties, uit te besteden. Bij uitbesteding is het belangrijk dat grenzen duidelijk worden vastgelegd: de aansturing van de uitbestede IT-activiteiten en de bepaling van de gewenste informatievoorziening in de organisatie moet bij de gebruikersorganisatie zelf worden belegd. Een organisatie dient zelf aan het roer te staan en wil niet door anderen laten bepalen wat men wel en niet moet doen als het gaat om de eigen informatievoorziening. Functioneel beheer vervult als intermediair tussen IT en de organisatie deze rol. Tussen de gebruikersorganisatie en de IT-serviceorganisatie bestaan echter verschillen - deze worden verderop in deze paragraaf uitgewerkt - die het maken van duidelijke afspraken over de te leveren diensten bemoeilijken. De delta tussen deze organisaties kan worden overbrugd door wederzijdse afstemming. Deze afstemming kan worden geffectueerd 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 (DAPs).

    Op operationeel niveau worden de gemaakte afspraken concreet vertaald en vastgelegd.

  • Afstudeerscriptie team 801 blz. 12 van 49

    Figuur 1, opgenomen in hoofdstuk 1, is verder uitgewerkt en het resultaat hiervan is weergegeven in het onderstaande figuur: Gebruikersorganisatie IT-serviceorganisatie Externe

    leverancier

    Figuur 2: wederzijdse afstemming gebruikersorganisatie en IT-serviceorganisatie

    2.2.1 Kenmerken/typering van de gebruikersorganisatie

    De gebruikersorganisatie is de organisatie die verantwoordelijk is voor de uitvoering van de bedrijfsprocessen die door de informatievoorziening worden ondersteund. Deze organisatie betreft zowel de eindgebruikers van een informatiesysteem als het middel- en het hogere management binnen deze organisatie. Een veelgebruikt synoniem voor gebruikersorganisatie is business en in de terminologie van de SLA: klant of afnemer van de diensten. De gebruikersorganisatie richt zich op het uitvoeren van activiteiten met als doel het verwezenlijken van de bedrijfsdoelstellingen en -functies van de organisatie. Een adequate beschrijving van de wijze waarop een gebruikersorganisatie er voor kan zorgen dat de informatievoorziening goed werkt is bijvoorbeeld opgenomen in het zgn. Business Information Service Library (BISL)-framework 4. Daar wordt ook aangegeven hoe behoeften vanuit het bedrijfsproces worden vertaald naar IT-oplossingen en hoe er wordt gestuurd op de informatievoorziening. Daar waar ITIL zicht richt op de IT-serviceorganisatie, focused het BISL zich op de gebruikersorganisatie. Het framework wordt ondersteund door best-practices die betrekking hebben op functioneel beheer en informatiemanagement.

    4 BISL Business Information Services Library, June 2007

    Under-pinning contract

    (UC)

    Leveran-cier: A B C

    Contract

    SLA

    DAP

    Behoeften

    Diensten

    Opera-tional Level Agree-ment (OLA)

    Kaders

    Randvoorwaarden

  • Afstudeerscriptie team 801 blz. 13 van 49

    2.2.2 Kenmerken/typering van de IT-serviceorganisatie

    De IT-serviceorganisatie (of leverancier) levert alle diensten op het gebied van technisch beheer en applicatiebeheer die nodig zijn om invulling te geven aan de voor de gebruikersorganisatie benodigde informatievoorziening. De IT-serviceorganisatie kan bij de levering van de IT-diensten gebruik maken van externe leveranciers. Deze externe leveranciers zullen opereren ten behoeve van meerdere opdrachtgevers en zijn dus actief in meerdere IT-serviceorganisaties (zie figuur 1). De IT-Serviceorganisatie is technisch georinteerd en concentreert zich op het leveren van technische IT diensten die gericht zijn op de ondersteuning van de bedrijfsprocessen van een gebruikersorganisatie. De tegenhanger van BISL bij de gebruikersorganisatie is de Information Technology Infrastructure Library (ITIL)5 bij de IT-serviceorganisatie. Het is een referentiekader voor het inrichten van beheerprocessen binnen een IT-organisatie. Het is geen methode of model maar een set best-practices.

    2.2.3 Verschillen tussen de gebruikers- en IT-serviceorganisatie

    Zoals in paragraaf 2.2.1 en 2.2.2 is beschreven bestaan er verschillen tussen de gebruikers- en IT-serviceorganisatie. Doelstellingen, belangen en werkwijzen verschillen onderling en kunnen conflicteren. Daarom is het met name voor een gebruikersorganisatie noodzakelijk dat afspraken tussen gebruikers- en IT-serviceorganisaties worden gemaakt. Er moeten in ieder geval over de volgende twee 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, SLEs) worden vastgelegd in een SLA. 2.3 Wat is de definitie van een Service Level Agreement?

    Uit literatuurstudie blijkt dat er gn eenduidige betekenis is te ontdekken voor het begrip Service Level Agreement. Vanuit de bestudeerde literatuur is een beeld gevormd over wat een SLA is. Indien van toepassing zijn bronverwijzingen opgenomen naar de gehanteerde literatuur. Over de kern van het begrip bestaat wl overeenstemming tussen de verschillende auteurs die zijn geraadpleegd. Die kern houdt in dat een SLA een overeenkomst is tussen een gebruikersorganisatie en een IT-serviceorganisatie waarbij een voor de gebruikersorganisatie minimum aanvaardbaar serviceniveau wordt vastgelegd. Uit literatuuronderzoek6 blijkt dat er nogal wat verschillende omschrijvingen worden gegeven van het begrip SLA. Vier voorbeelden daarvan: Een SLA is geen wettelijk contract, dat wil zeggen het heeft niet het waterdichte

    karakter van een contract en geen wettelijke invloed. Clausules in een SLA zijn niet juridisch afdwingbaar.

    Een SLA is meer dan een resultaat van een onderhandelingsproces. Het wordt gecreerd om de gemeenschappelijke opvattingen over de te leveren diensten

    5 ITIL Information Technology Infrastructure Library, versie 3 6 D. Vandaele en P. Gemmel, Service Level Agreements: een literatuuroverzicht 2004

  • Afstudeerscriptie team 801 blz. 14 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 de verantwoordelijkheden van de klant te bevatten.

    In een SLA dient een formulering te worden opgenomen die bepaalt wat er moet gebeuren als een dienst niet geleverd wordt. Daarnaast moet de SLA een schema bevatten met de kosten en middelen die nodig zijn voor de uitvoering van de overeenkomst.

    Naast de verschillende omschrijvingen kan uit de literatuur een aantal gemeen-schappelijke kenmerken worden afgeleid. En van deze kenmerken is dat een SLA zowel door de gebruikersorganisatie als door de IT-serviceorganisatie goedgekeurd en ondertekend moet worden. Dit betekent dat beide organisaties verantwoordelijk zijn voor de in de SLA vastgelegde afspraken. Hierbij is het belangrijk dat de IT-serviceorganisatie zowel rekening houdt met de behoeften van de gebruikersorganisatie als met de eigen mogelijkheden. Daarom moet voor het bepalen van het serviceniveau een afweging worden gemaakt tussen de verschillende belangen. Er wordt gebruik gemaakt van verschillende criteria bij het vastleggen van het minimale serviceniveau. Voor deze criteria worden normen en prestatiemaatstaven vastgelegd. Hierdoor wordt de te leveren dienst gekwantificeerd, meetbaar en tastbaar. Om een SLA controleerbaar te maken is het belangrijk op te nemen hoe de prestaties worden gemeten en met welke frequentie over de realisatie wordt gerapporteerd.

    2.4 Welke soorten Service Level Agreements zijn te onderkennen?

    Iedere gebruikersorganisatie heeft andere behoeften en verwachtingen zodat iedere SLA er anders uit ziet. Hierdoor ontstaan veel verschillende soorten SLAs. Deze SLAs kunnen in categorien 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 categorien toegelicht: De relatie tussen de betrokken organisaties Van een interne SLA is sprake als de afnemer van de dienst behoort tot de organisatie die de dienst verleent. Ofwel: de gebruikersorganisatie en de IT-serviceorganisatie behoren tot dezelfde organisatie. Van een externe SLA is sprake als de afnemer van de dienst buiten de grenzen van de organisatie valt die de dienst levert. Ofwel: de gebruikersorganisatie en de IT-serviceorganisatie behoren niet tot dezelfde organisatie. Binnen de Rijksoverheid kunnen interne SLAs nog verder worden onderverdeeld in interdepartementale en intradepartementale. Wanneer een dienst wordt geleverd door een bepaalde afdeling van een organisatie aan een andere afdeling van dezelfde organisatie wordt gesproken over intradepartementaal. Als de dienstverlening plaatsvindt tussen twee onderdelen van verschillende ministeries wordt over gesproken over interdepartementaal.

  • Afstudeerscriptie team 801 blz. 15 van 49

    Onderstaande figuur geeft de indeling naar de verschillende soorten en categorien SLAs weer:

    Figuur 3: indeling soorten en categorien SLAs

    (bron: D. Vandaele en P.Gemmel, 2004)

    De structuur van de SLA Er worden in de geraadpleegde theorie drie structuren onderscheiden bezien vanuit het aantal gebruikersorganisaties en het aantal diensten die betrokken zijn bij de overeenkomst (zie figuur 2). Een eerste mogelijkheid: een IT serviceorganisatie kan per gebruikersorganisatie een SLA opstellen voor alle te leveren diensten. Het voordeel is dat deze werkwijze een goed overzicht verschaft en dat kan worden ingespeeld op de verschillende behoeften van diverse gebruikersorganisaties. Het nadeel is wel dat bij een verandering van de eisen van een gebruikersorganisatie de gehele SLA moet worden herzien. Een tweede mogelijkheid: een SLA kan worden afgesloten voor een bepaalde dienst die voor alle gebruikersorganisaties identiek is. Dit is alleen toepasbaar als de gebruikersorganisaties niet teveel van elkaar verschillen. Het voordeel is dat de dienstverlening overzichtelijk is. Een derde mogelijkheid: een IT-serviceorganisatie kan voor elke dienst en elke gebruikersorganisatie een andere SLA opstellen. Het nadeel hiervan is dat dit leidt tot een groot aantal SLAs waardoor de beheersing ervan wordt bemoeilijkt. Anderzijds biedt het ook voordelen: de SLA kan heel specifiek worden toegespitst op de wensen van de gebruikersorganisatie. Wanneer een gebruikersorganisatie het niveau van een dienst wil wijzigen, hoeft slechts over n SLA onderhandeld te worden.

    SLA

    Intern Extern

    Interdepartementaal Intradepartementaal

    Voor n dienst

    Voor alle diensten

    Voor n dienst

    Voor alle diensten

    Voor n dienst

    Voor alle diensten

  • Afstudeerscriptie team 801 blz. 16 van 49

    Het bindende karakter van de SLA SLAs kunnen worden onderscheiden in adviserende en contractuele SLAs. Voor beide SLAs geldt dat zij ondersteuning bieden bij de beheersing van de verwachtingen van de gebruikersorganisatie. Een kenmerkend verschil is dat bij adviserende SLAs geen financile sancties worden opgenomen. Contractuele SLAs worden opgesteld wanneer er behoefte bestaat aan een terugbetalingssysteem. Als de IT-serviceorganisatie onderdeel uitmaakt van de Rijksoverheid is in het algemeen geen sprake van contractuele SLAs met boetebepalingen. De Rijksoverheid vormt immers n rechtspersoon. Interdepartementale SLAs bevatten derhalve zelden financile boetebepalingen. Het gevolg van het ontbreken van financile consequenties kan zijn dat het verbeteren van de kwaliteit van een te leveren dienst niet wordt gestimuleerd. 2.5 Wat is het doel van het opstellen van een Service Level Agreement?

    Een SLA kent de volgende vier basisdoelstellingen 6: (tussen haakjes zijn de afgeleide, secundaire doelstellingen vermeld) Het opstellen van een SLA zorgt ervoor dat de behoeften van de

    gebruikersorganisatie duidelijk worden en in kaart kunnen worden gebracht; (het beheersen van de verwachtingen van de gebruikersorganisatie en het tevredenstellen van de gebruikersorganisatie);

    Het definiren van de noodzakelijke processen die nodig zijn om de behoeften en wensen van de gebruikersorganisatie te kunnen vervullen; (het efficint verdelen van de beschikbare middelen en het controleren van de uitgaven);

    Het opstellen van een prestatiemeetsysteem door de IT-serviceorganisatie criteria en maatstaven voor het meten van de prestaties te laten formuleren; (het meten van tevredenheid van de gebruikersorganisatie; het vergelijken van prestaties en het inzicht krijgen in de eigen concurrentiepositie);

    Het managen van de relatie met de gebruikersorganisatie; (het vermijden van conflicten en het verhogen van de klantenbinding).

    2.6 Hoe komt een Service Level Agreement idealiter tot stand? 2.6.1 Proces Een SLA komt tot stand door de voortdurende afstemming tussen klant (gebruikers-organisatie) en leverancier (IT-serviceverlener), waarbij de klant de behoefte van zijn organisatie moet kennen en de leverancier de (on)mogelijkheden van zijn organisatie 7. Dat klinkt eenvoudig, maar is het niet. Wie is bijvoorbeeld de klant: alle gebruikers, een vertegenwoordiging van de gebruikers, de manager? Kent die klant de behoeften? Kent de leverancier zijn eigen organisatie goed genoeg? Het is niet mogelijk een standaard SLA op te stellen omdat elke situatie specifieke omstandigheden heeft waar een SLA op moet worden aangepast.

    6 D. Vandaele en P. Gemmel, Service Level Agreements: een literatuuroverzicht, 2004 7 P.F.L. van Scheffel c.s. - Het doel, de weg en de rugzak (2004)

  • Afstudeerscriptie team 801 blz. 17 van 49

    In de literatuur worden verschillende methoden besproken voor het opstellen van een SLA 8. Deze methoden laten veel overeenkomsten zien in de verschillende stappen in het proces. Om te komen tot een SLA moeten of kunnen de volgende stappen worden doorlopen: 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 die

    vastgelegd 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 personeelsleden

    die verantwoordelijk zijn voor het succesvol afhandelen van de SLA; En de pre-implementatie: het ontwikkelen van het prestatiemeetsysteem, het

    opzetten van een rapporteringproces.

    3) Het beheer van de SLA. Over de volgende onderwerpen moeten afspraken worden 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 te krijgen en te houden is het belangrijk dat de SLA wordt opgesteld voor een beperkte periode en dat die regelmatig wordt aangepast aan de veranderingen in de organisaties en aan de ontwikkelingen in de IT. Het is goed om een SLA te beschrijven in de terminologie van de gebruikersorganisatie 9. De bedrijfsdoelstellingen van de gebruikersorganisatie moeten duidelijk naar voren komen in een SLA. Hierdoor kan de vertegenwoordiger van de gebruikersorganisatie eenvoudiger de afspraken en rapportages binnen de eigen organisatie communiceren. Daarnaast is het dan voor de IT-serviceorganisatie mogelijk de dienstverlening te leveren die daadwerkelijk aansluit op de doelstellingen van de gebruikersorganisatie. Een SLA moet worden gezien als een levend document en de gebruikersorganisatie en IT service- organisatie moeten periodiek met elkaar om tafel om te onderhandelen over de afspraken in de SLA.

    Ter illustratie is in bijlage 1 van deze scriptie een voorbeeld van een SLA opgenomen waarin 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, Syntegra

  • Afstudeerscriptie team 801 blz. 18 van 49

    2.6.2 Betrokkenen

    Het is belangrijk dat bij het opstellen van een SLA de juiste personen van beide organisaties aan tafel zitten. Dit omdat een gebruikersorganisatie een SLA wil hebben die toereikend is en de IT-serviceorganisatie een SLA wil hebben die (financieel) haalbaar is. Meestal worden SLAs opgesteld in een samenwerkingsverband tussen de Informatiemanager en de Service Level Manager. De Informatiemanager vertegenwoordigt de gebruikersorganisatie en heeft kennis van de bedrijfsdoelstellingen en de wensen van de gebruikers. Hij opereert op het snijvlak van IT-expert en IT-gebruiker. De Service Level Manager vertegenwoordigt de IT-serviceorganisatie en houdt rekening met het beleid en de mogelijkheden van zijn organisatie. 2.7 Wat houdt beveiliging in vanuit IV-dienstverleningsperspectief?

    Uit de literatuur komt naar voren dat er in de afgelopen tijd een toenemende behoefte waarneembaar is die betrekking heeft op het beschikbaar zijn en het verstrekken van informatie. Dit uit zich vervolgens in een toename van de informatie-uitwisseling tussen enerzijds de Rijksoverheid en anderzijds de burgers en bedrijven. Door gebruikersorganisaties binnen de Rijksoverheid worden steeds meer diensten uitbesteed aan IT-serviceorganisaties. Bij deze uitbesteding blijft de gebruikersorganisatie zelf verantwoordelijk voor die diensten. Daarom stelt zij eisen aan de IT-serviceorganisaties ten aanzien van de informatiebeveiliging. In deze paragraaf wordt ingegaan op het ruimere begrip zoals dat bij de Rijksoverheid wordt gehanteerd, met als doel tot een goede begripsafbakening te komen. Beveiliging bestaat uit een aantal verschillende disciplines. Onder integrale beveiliging 10 wordt verstaan: informatiebeveiliging, fysieke beveiliging en personele beveiliging 11. Bij informatiebeveiliging gaat het om betrouwbaarheidseisen. Bij fysieke beveiliging gaat het om veiligheidscriteria. En bij personele beveiliging gaat het om de wettelijke arbo-eisen. Om te komen tot een evenwichtig beveiligingspakket in een organisatie is het belangrijk de drie disciplines van beveiliging in samenhang te beschouwen. Deze vakgebieden liggen dicht tegen elkaar aan en overlappen elkaar gedeeltelijk. Voor het stellen van eisen aan IT-serviceorganisaties heeft met name informatiebeveiliging een directe betekenis, de eisen van de andere disciplines zullen verder niet worden behandeld. De drie beveiligingsaspecten resulteren in een stelsel van maatregelen, die zijn afgestemd op de te beschermen belangen. Binnen organisaties moeten risicoafwegingen worden gemaakt door het onderkennen van afhankelijkheden en bedreigingen. Hierbij moet rekening worden gehouden met de geldende wet- en regelgeving. Binnen de Rijksoverheid zijn diverse voorschriften van kracht die ingaan op informatiebeveiliging, waaronder bijvoorbeeld het Voorschrift Informatiebeveiliging Rijksdienst 2007 (VIR 2007)12 en het Veiligheidsvoorschrift Rijksdienst 2005 13.

    10 Douwe P. de Jong RSE, Integrale beveiliging, Dikke muren en firewalls, 2003 11 W. Barnhoorn c.s. - Outsourcing (2001) 12 Besluit Voorschrift Informatiebeveiliging Rijksdienst (2007)

  • Afstudeerscriptie team 801 blz. 19 van 49

    Daarnaast worden binnen de Rijksoverheid diverse best practices en andere vormen van wet- of regelgeving gehanteerd die betrekking hebben op informatiebeveiliging: de Code voor Informatiebeveiliging en ITIL Security Management. De genoemde voorschriften en best practices worden nog kort toegelicht. Voorschrift Informatiebeveiliging Rijksdienst 2007

    De essentie van het VIR 2007 is ervoor te zorgen dat de overheid op een betrouwbare manier omgaat met gegevens van burgers en bedrijfsleven. De overheid is daarbij afhankelijk van informatietechnologie. Voor de beschikbaarheid van geautomatiseerde of handmatige informatiesystemen worden meestal Service Level Agreements (SLA) - of vergelijkbare overeenkomsten met een andere benaming - afgesloten tussen de eigenaar van het informatiesysteem (uiteindelijk lijnmanagement) en de IT dienstenleverancier. Beveiliging is daarin een onderdeel van de afspraken. Veiligheidsvoorschrift Rijksdienst 2005

    Het Veiligheidsvoorschrift Rijksdienst 2005 geeft aan dat de secretaris-generaal verantwoordelijk is voor de integrale beveiliging van de organisatie, de medewerkers, het materieel, de informatiesystemen, de gebouwen en de overige objecten en de inrichting en de werking van de beveiligingsorganisatie. De secretaris-generaal wijst een beveiligingsambtenaar aan die de verantwoordelijkheid voor integrale beveiliging krijgt overgedragen. In het voorschrift is opgenomen dat onder integrale beveiliging wordt verstaan: een afgewogen en consistente toepassing van beveiligingsmaatregelen in een breed scala 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 SLAs: In de Code voor Informatiebeveiliging 14 wordt op contractniveau - niet op het gedetailleerde niveau van de SLA - ingegaan op beveiligingseisen die behoren bij uitbesteding. Om de bijbehorende beveiliging te regelen wordt een aantal maatregelen geadviseerd, bijvoorbeeld op het gebied van fysiek- en logisch toegangsbeheer of het recht om te mogen auditen. ITIL is een best practice voor IT-beheerprocessen. ITIL beoogt meer grip te krijgen op de kwaliteit van de IT-dienstverlening. Het basisprincipe van ITIL is, dat de IT serviceorganisaties diensten leveren aan de afnemers (gebruikersorganisaties) tegen wat heet gerechtvaardigde kosten. Het ITIL proces Security Management 15 geeft de structurele inpassing van beveiliging in de IT-beheerorganisatie en moet ervoor zorgen dat de dienstverlening blijft voldoen aan de met de klant afgesproken eisen op het gebied van de informatiebeveiliging. De SLA valt onder de verantwoordelijkheid van het Service Level Management en fungeert als stuurinstrument voor de ITIL-processen.

    In bijlage 2 zijn de bovengenoemde voorschriften en best practices nader uitgewerkt terug te vinden.

    13 Veiligheidsvoorschrift Rijksdienst 2005 14 Code voor Informatiebeveiliging (NEN-ISO-IEC 17799:2005) 15 J. Bon, G. Kemmerling en D. Pondman, IT servicemanagement, an introduction ITSMF (2002)

  • Afstudeerscriptie team 801 blz. 20 van 49

    3 Uitkomsten praktijkonderzoek 3.1 Inleiding In dit hoofdstuk zijn de belangrijkste bevindingen weergegeven die vanuit de praktijk naar voren zijn gekomen. De informatie is verkregen door het houden van interviews met behulp van een gestructureerde vragenlijst (zie bijlage 3). De vragen voor de interviews zijn thematisch geclusterd en ook op die wijze voorgelegd aan de genterviewden. Het doel van de interviews is: Het vaststellen of er naast de elementen genoemd in de literatuur nog

    elementen vanuit de praktijk naar voren komen die relevant zijn voor het onderzoek;

    Nagaan of de bestudeerde literatuur toegepast is bij de voor het onderzoek gehanteerde casus;

    Het beantwoorden van de deelvragen. Om te beginnen is getracht inzicht te verkrijgen in wat in de praktijk wordt verstaan onder een SLA en wat de relevantie ervan is in de dagelijkse bedrijfsvoering van zowel de gebruikersorganisatie als de IT-serviceorganisatie. Vervolgens is het totstandkomingsproces van een SLA in stukjes geknipt om zo duidelijkheid te verkrijgen over de te onderscheiden procesfasen die een SLA kenmerkt, gedurende zijn levenscyclus van ontwerp tot evaluatie. Als afsluiting van dit hoofdstuk wordt ingegaan op de meer inhoudelijke kant van de SLA. Daarbij is vooral gekeken naar de wijze waarop het gewenste kwaliteitsniveau van de afspraken wordt bereikt. Tenslotte is ingegaan op de beveiligingsparagraaf: wat verstaat men onder beveiliging en hoe wordt het beveiligingsbegrip ingevuld. 3.2 Algemeen Betekenis van een SLA

    Een SLA wordt door de genterviewden omschreven als een overeenkomst tussen een gebruikersorganisatie en een IT-serviceorganisatie. Dit blijkt te gelden voor alle betrokken partijen. De betekenis van de SLA is voor beide partijen identiek. Doel van een SLA

    Vanuit de praktijk zijn verscheidene doelen van een SLA genoemd. Een SLA wordt gezien als een hulpmiddel om een abstract begrip als goed functioneren concreet te vertalen naar wederzijdse afspraken. De afspraken tussen twee partijen worden vastgelegd. Hierbij gaat het enerzijds om de wens en de behoefte vanuit de gebruikersorganisatie en anderzijds om de mogelijkheden van een IT-serviceorganisatie om de gevraagde dienst te kunnen leveren. In de SLA worden de afspraken over bijvoorbeeld taken, bevoegdheden en verantwoordelijkheden helder en eenduidig overeengekomen en vastgelegd. Hierdoor worden in een SLA de rechten en plichten van zowel de gebruikersorganisatie als de IT-serviceorganisatie uitgewerkt. Aangegeven is dat het reduceren van risicos een belangrijk doel is van een SLA.

  • Afstudeerscriptie team 801 blz. 21 van 49

    Uitgangspunten en randvoorwaarden

    Vanuit 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 te verdwijnen. Bewustwording van het belang is eveneens een belangrijke randvoorwaarde om een SLA te laten functioneren zoals bedoeld. Een andere belangrijke randvoorwaarde die in de praktijk naar voren is gekomen is dat een SLA een beperkte looptijd/geldigheidsduur moet hebben, omdat de SLA dan kan worden aangepast aan de veranderende omgeving. Onder beperkte looptijd wordt hierbij ca. 12 maanden verstaan.

    3.3 Lifecycle van een SLA Aanleiding van een SLA

    De aanleiding voor het opstellen van een SLA is het helder vastleggen van afspraken over een te leveren dienst tussen twee partijen met als belangrijkste doel het reduceren van mogelijke risicos. De risicos die gezien worden zijn bijvoorbeeld het niet nakomen van afspraken maar ook onduidelijkheid over wat men van elkaar verwacht. Wanneer de IT-dienstverlening niet voldoet aan de overeengekomen beheersdoelstellingen en dienstenniveaus, bestaat het risico dat de gebruikersorganisatie haar bedrijfsdoelstellingen niet haalt en daarmee financile en/of reputatieschade lijdt. De IT-serviceorganisatie kan eveneens reputatieschade lijden en bij uitbesteding ook financile schade lijden als er sprake is van boetebepalingen. Ontwikkelen van een SLA

    Uit de interviews is gebleken dat alle gebruikte SLAs zijn gebaseerd op een algemeen aanvaard normenkader. Meestal aangereikt door de IT-serviceorganisatie. Voor de in het onderzoek meegenomen casussen is gebruik gemaakt van ITIL. De redenen die aangegeven zijn voor het gebruik van ITIL zijn: De IT-serviceorganisaties zijn vaak ingericht op basis van de processen

    beschreven in ITIL omdat zij het gebruiken voor het beheer van de IT-infrastructuur;

    Het in de IT-branche een veel gebruikte richtlijn is voor het beheer van IT-infrastructuur;

    Het praktische handvatten biedt voor uniform beheer van een steeds complexer wordende IT-infrastructuur.

    In de praktijk is aangegeven dat het bij de totstandkoming van een SLA belangrijk is een goed team samen te stellen. Dit houdt in dat de juiste personen met elkaar om de tafel komen te zitten. Dit is een voorwaarde om de samenwerking tussen beide organisaties succesvol te laten verlopen. Uit het onderzoek is gebleken dat de belanghebbenden van de IT-dienstverlening binnen de IT-serviceorganisatie en binnen de gebruikersorganisatie worden betrokken bij de totstandkoming van de SLA. Hier kan het gaan om fysieke of virtuele teams. IT-auditors worden in de praktijk meestal achteraf ingeschakeld (bij een audit of ter verificatie) en minder vaak bij de opzet van een SLA. In een SLA moeten de afspraken over een te leveren dienst zoveel als mogelijk concreet en meetbaar worden gemaakt.

  • Afstudeerscriptie team 801 blz. 22 van 49

    Dit is aangegeven als vanzelfsprekendheid, maar in de praktijk blijkt het meetbaar maken van kwaliteitsnormen lastig te zijn. De perceptie van de gebruikersorganisatie blijkt anders dan die van de IT-serviceorganisatie. De rechten en plichten van zowel de gebruikersorganisatie als de IT-serviceorganisatie moeten ook in de SLA worden uitgewerkt. Aangegeven is dat dit niet altijd heel gedetailleerd gebeurt. Het risico bestaat dat verantwoordelijkheden op organisatieniveau worden belegd en niet op het functionarisniveau, waardoor onduidelijkheden ontstaan over wie waarvoor verantwoordelijk is. Transparantie is eerder in dit hoofdstuk al benoemd als doel van een SLA. In de praktijk blijkt echter dat voordat uiteindelijk transparantie wordt bereikt omtrent de overeengekomen afspraken er voorafgaand een intensief proces moet worden doorlopen. In dit proces worden veel conceptversies tussen de beide partijen uitgewisseld totdat een definitieve versie wordt bereikt. Testen van een SLA

    Met het testen wordt bedoeld dat voordat een SLA operationeel wordt, wordt nagegaan of alle betrokkenen van een SLA de overeengekomen definitieve afspraken op eenzelfde wijze interpreteren. In de praktijk is gebleken dat testen geen expliciet onderdeel is van het totstandkomingproces. Over een testprocedure lijkt niet te zijn nagedacht. Alleen het uitwisselen van conceptversies wordt als een soort testproces gezien. Gebruik van de SLA

    Voordat een SLA in gebruik genomen kan worden, is het noodzakelijk dat beide partijen de SLA ondertekenen. Zonder ondertekening heeft een SLA geen rechtsgeldigheid en kunnen er geen rechten aan worden ontleend. Uit het onderzoek is gebleken dat de SLAs inderdaad worden ondertekend door de verantwoordelijke leidinggevenden in de organisaties. Zoals is aangegeven in dit hoofdstuk is een randvoorwaarde voor een goede werking van een SLA dat het een levend document moet zijn. Dit betekent dat betrokken partijen zich bewust zijn van de SLA en de hierin opgenomen afspraken. Tijdens het praktijkonderzoek is gebleken dat een SLA binnen een IT-serviceorganisatie meer leeft dan in een gebruikersorganisatie. In de gesprekken is aangegeven dat dit komt door een verschil in belangen: de gebruikersorganisatie wil dat de dienstverlening goed functioneert en het maakt hen weinig uit op welke wijze. De IT-serviceorganisatie daarentegen wil zich houden aan de afspraken in de SLA en voorkomen dat door de gebruikersorganisatie meer gevraagd wordt dan is afgesproken. Bij meningsverschillen tussen beide partijen over de dienstverlening valt de IT-serviceorganisatie vaak terug op de SLA. Binnen de Rijksoverheid wordt in het algemeen geen gebruik gemaakt van contractuele SLAs met boeteclausules. De Rijksoverheid vormt immers n rechtspersoon waardoor geen sprake is van twee organisaties met verschillende (tegengestelde) belangen. Vanuit de interviews komt naar voren dat vanuit de gebruikersorganisatie soms wel behoefte bestaat aan het opnemen van sancties in een SLA voor het niet nakomen van de afspraken. De enige vorm die is aangetroffen is het (tijdelijk) opschorten van betalingen bij het niet nakomen van de gemaakte afspraken.

  • Afstudeerscriptie team 801 blz. 23 van 49

    Evaluatie van de SLA Rapportages over de gerealiseerde dienstenniveaus en beheersdoelstellingen worden door de IT-serviceorganisatie opgesteld en door de gebruikersorganisatie beoordeeld. Vervolgens worden de rapportages besproken tussen beide organisaties. 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. Er worden daarentegen wel aanvullende afspraken gemaakt. 3.4 Inhoud van een SLA (algemeen) Bedrijfsdoelstellingen

    Een relatie tussen de (bedrijfs)doelstellingen van de gebruikersorganisatie en de verwoording ervan in de SLA ligt voor de hand. Immers, de te verrichten werkzaamheden door de IT-serviceorganisatie kunnen op die manier in lijn worden gebracht met de resultaten die de gebruikersorganisatie wil bereiken. Bedrijfsdoelstellingen zijn echter niet aangetroffen in de SLAs. Als de gebruikersorganisatie zijn doelstellingen echter vertaalt in heldere eisen voor de IT-serviceorganisatie, is het verwoorden van de bedrijfsdoelstellingen overbodig.

    Samenstelling SLA

    In de onderzochte praktijk is gebleken dat bij het opstellen van een SLA gebruik gemaakt wordt van een template of standaard SLA die door de IT-serviceorganisatie wordt aangereikt. Deze gehanteerde templates zijn gebaseerd op de ITIL-beheerprocessen. Kwaliteitsniveau

    Uit het onderzoek is gebleken dat het kwaliteitsniveau van een SLA voor een groot deel wordt bepaald door hoe de afspraken zijn gemaakt en vastgelegd. Vanuit de praktijk is aangegeven dat het voor de hand ligt dat afspraken helder, concreet en meetbaar moeten zijn. Hoe concreter de afspraken zijn gemaakt hoe beter werkbaar ze zijn. Een voorbeeld daarvan zijn de tijdstippen waarop verantwoordingsrapportages worden opgeleverd, bijvoorbeeld n keer per kwartaal. Daarnaast wordt in de praktijk meestal de inhoud en opbouw van de rapportages eenduidig - en van te voren - vastgelegd. Naast het maken van concrete afspraken is aangegeven dat het belangrijk is dat de overeengekomen afspraken voor beide partijen op dezelfde wijze worden genterpreteerd. Voor het vaststellen van het kwaliteitsniveau van de geleverde dienstverlening en het vereiste beveiligingsniveau ligt het voor de hand om kwaliteitsnormen af te spreken. Vervolgens kunnen die normen in meetbare eenheden worden vertaald. Zowel het definiren van die kwaliteitsnormen als het meten ervan blijkt echter een lastige opgave te zijn. Dit heeft met name te maken met de verschillende percepties van de gebruikers- en IT-serviceorganisatie over dezelfde onderwerpen. In de SLAs wordt niet vastgelegd welk normenkader wordt gehanteerd in relatie tot de informatiebeveiliging.

  • Afstudeerscriptie team 801 blz. 24 van 49

    3.5 Inhoud van een SLA (beveiliging)

    Wat is beveiliging?

    In ons onderzoek geven de partijen waarmee is gesproken een eenduidig antwoord op de vraag wat onder beveiliging wordt verstaan. De kwaliteitsaspecten beschikbaarheid, integriteit en exclusiviteit worden in alle gevallen spontaan genoemd. VIR en ITIL

    Binnen de Rijksoverheid weten zowel de gebruiker als de dienstverlener zich aan het VIR gebonden. Vaak is het VIR doorvertaald naar interne richtlijnen die specifiek gelden voor een departement of organisatieonderdeel. Dat wordt dus ook als uitgangspunt gehanteerd. Omdat de IT-serviceorganisatie vaak het meeste bijdraagt aan de totstandkoming van een SLA, ligt het voor de hand dat ITIL wordt gebruikt als referentiekader. ITIL sluit immers goed aan bij de technische processen van de IT-serviceorganisatie. Alle bekeken SLAs waren op ITIL gebaseerd. Richtlijnen

    Uit de gesprekken is naar voren gekomen dat er veel interne richtlijnen bestaan waar de Rijksoverheid zich aan dient te houden. In de loop van de tijd worden vaak richtlijnen toegevoegd en vinden er aanpassingen plaats. Momenteel is een duidelijk tegengestelde beweging ingezet: het doelbewust verminderen van het aantal en de omvang van de richtlijnen, waardoor meer duidelijkheid en eenduidigheid wordt bereikt. Daarnaast is aangegeven dat de richtlijnen ook bekend moeten zijn bij de betrokken medewerkers. Er is nog wel eens sprake van een dik boek dat in de kast staat, dat niet wordt gelezen en waarvan de inhoud maar mondjesmaat bekend is. Het inzetten van ondersteunende technische hulpmiddelen (bijvoorbeeld beeldkrantberichten) en mondelinge voorlichting om zowel bewustwording als bekendheid met de afspraken en regels te vergroten wordt daarom als bruikbaar gereedschap gezien en regelmatig ingezet.

  • Afstudeerscriptie team 801 blz. 25 van 49

    4 Het auditinstrument 4.1 Inleiding In dit hoofdstuk worden de antwoorden gegeven op de drie laatste deelvragen die zijn 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 Level

    Agreement voldoen? 11. Hoe kan getoetst worden of in de Service Level Agreement de essentile

    onderwerpen zijn benoemd? Het antwoord op de vragen 9 en 10 is samengebracht in een auditinstrument. Dit instrument bevat de hoofd- en subcategorien die een rol spelen bij zowel de beoordeling 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 in het instrument opgenomen vragen te stellen en te beantwoorden. De mate waarin de vragen positief kunnen worden beantwoord is een goed criterium voor de kwaliteit van de SLA. 4.2 Het instrument

    Op basis van theorie (H2) en praktijk (H3) zijn er zowel overeenkomsten als verschillen vastgesteld. 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 te

    opdrachtgever (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 voorwaarde

    voor succes bij het opstellen en gebruik van een SLA; Er bestaat geen template van een ideaal-SLA, maar er is wel een set met

    onderdelen die er in ieder geval in thuishoren; Onder beveiliging wordt verstaan: beschikbaarheid, integriteit en

    vertrouwelijkheid; Bij de Rijksoverheid geldt het VIR voor beide partijen en wordt ook als zodanig

    onderkend. Het ITIL is met name van toepassing op de IT-serviceorganisatie en wordt intensief toegepast. Voor de gebruikersorganisatie kan gebruik worden gemaakt van BiSL, maar dit komt niet erg prominent naar voren;

    Beveiliging vormt een integraal onderdeel van een SLA, maar wordt niet als bijzonder onderdeel gezien en behandeld.

  • Afstudeerscriptie team 801 blz. 26 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 praktijk

    wordt dat sterk benadrukt. In de theorie wordt weliswaar aangegeven dat de totstandkoming van een SLA een actief proces is tussen beide partners, maar over de fase n de totstandkoming rekening houdend met alle randvoorwaarden, wordt niet veel gezegd;

    In de theorie vormt de testfase een wezenlijk onderdeel van een ontwikkelproces. In de praktijk wordt dat niet vertaald naar een concrete activiteit die vr ingebruikname van de SLA dient plaats te vinden;

    Er zijn eenduidige normen beschikbaar die betrekking hebben op informatiebeveiliging. Ze worden misschien wel toegepast, maar niet vastgelegd in de SLAs. Ook over de toetsing van de werking ervan worden geen afspraken gemaakt.

    Door de theorie en de bevindingen vanuit het praktijkonderzoek over de opzet, het bestaan en de werking van een SLA, met elkaar in verband te brengen is een instrument tot stand gekomen. Het is opgenomen in bijlage 4. Dit instrument kan gebruikt worden door een adviseur die wordt gevraagd om de totstandkoming van een goede SLA te begeleiden of door een auditor om de kwaliteit van een bestaande of reeds ontwikkelde SLA te beoordelen. Het instrument is opgebouwd in de vorm van een tabel. De tabel is verdeeld in 4 kolommen. De eerste kolom bevat de hoofdcategorien. Deze hoofdcategorien zijn ingedeeld op dezelfde wijze als genoemd in hoofdstuk 2: algemeen, lifecycle van een SLA, inhoud van een SLA algemeen en inhoud specifiek met betrekking tot het onderwerp informatiebeveiliging. In tabelvorm, onderdeel van het auditinstrument ziet dat er als volgt uit: Hoofdcategorie

    Algemeen

    Lifecycle SLA

    Inhoud van een SLA

    (algemeen)

    Inhoud van een SLA

    (beveiliging)

    Vervolgens zijn in de tweede kolom per hoofdcategorie, subcategorien opgenomen. Voor de hoofdcategorie Algemeen zijn de volgende onderwerpen benoemd: doelen, randvoorwaarden en uitgangspunten en rechten en plichten. Voor Lifecycle van een SLA zijn deze onderwerpen benoemd: aanleiding totstandkoming SLA, ontwikkelen, testen, gebruik en evaluatie van de SLA. Met betrekking tot de hoofdcategorie Inhoud van een SLA algemeen, zijn de volgende onderwerpen opgenomen: bedrijfsdoelstellingen, samenstellen van een SLA en het kwaliteitsniveau.

  • Afstudeerscriptie team 801 blz. 27 van 49

    De laatste hoofdcategorie, Inhoud van een SLA met betrekking tot het onderwerp beveiliging, bevat de volgende onderwerpen: begrip beveiliging, referentiekaders, regelgeving en incidenten. Zie de volgende tabel. Hoofdcategorie Subcategorie

    Doelen

    Randvoorwaarden en uitgangspunten

    Algemeen

    Rechten en plichten

    Aanleiding totstandkoming SLA

    Ontwikkelen

    Testen

    Gebruik van de SLA

    Evaluatie van de SLA

    Lifecycle SLA

    Bedrijfsdoelstellingen

    Samenstellen SLA

    Kwaliteitsniveau

    Inhoud van een SLA

    (algemeen)

    Begrip Beveiliging

    Referentiekaders

    Regelgeving

    Inhoud van een SLA

    (beveiliging)

    Incidenten

    De derde kolom van de tabel geeft per subcategorie vervolgens de aandachtspunten en vragen weer die zowel gesteld kunnen worden aan de te interviewen 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 dus met ja of nee beantwoord worden. Hiermee kan snel inzicht worden verkregen of in hoofdlijnen aan de belangrijkste onderwerpen aandacht is besteed. Hieronder is, ter verduidelijking, een deel van het instrument weergegeven: Lifecycle SLA Gebruik van de SLA Is de SLA door beide partijen

    ondertekend? Is de SLA een levend document voor beide betrokken partijen? Zijn er sancties opgenomen in de SLA?

    J/N J/N J/N

    De volledige tabel is opgenomen in bijlage 4. In aanvulling op deze tabel is een vragenlijst toegevoegd waarmee dieper wordt ingegaan op de genoemde categorien. Deze vragen kunnen behulpzaam zijn als, in eerste instantie, het antwoord op n van de genoemde vragen uit de tabel ontkennend is. Op dat moment kunnen aanvullende vragen worden gesteld om inzicht in de actuele situatie te verkrijgen.

  • Afstudeerscriptie team 801 blz. 28 van 49

    5 Conclusies en aanbevelingen Dit hoofdstuk omvat de conclusies en aanbevelingen die zijn voortgekomen uit de bevindingen 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 een

    Service Level Agreement (SLA) worden gesteld, om de afstemming tussen de

    gebruikersorganisatie en de IT-serviceorganisatie binnen de Rijksoverheid vast te

    leggen, waarbij ook de noodzakelijke informatiebeveiliging in opzet, bestaan en

    werking in de IV-dienstverleningsketen is geborgd?

    Uit het literatuur- en praktijkonderzoek blijkt dat een SLA een nuttig middel is om afspraken tussen twee organisaties eenduidig vast te leggen. Er zijn elementen naar voren gekomen die belangrijk zijn voor de totstandkoming van een SLA, maar ook belangrijk zijn bij de toetsing van het gebruik van een SLA. Het is mogelijk gebleken deze elementen te vatten in een auditinstrument. Dit auditinstrument kan gebruikt worden door een auditor of adviseur om een SLA te toetsen of aan de eisen wordt voldaan die aan een SLA worden gesteld. In het auditinstrument zijn de elementen in de volgende hoofd- en subcategorien ingedeeld: 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 categorien moeten in ieder geval worden meegenomen bij de totstandkoming van een SLA om te zorgen voor een goede afstemming tussen beide partijen. De noodzaak voor het gebruik van een dergelijk auditinstrument wordt gevoed door de discrepantie die er is tussen de theorie en de praktijk. Om dat verschil goed te kunnen toetsen en om te beoordelen of de afstemming wel volledig is, kan het instrument behulpzaam zijn. Het instrument is (nog) niet gevalideerd. Geadviseerd wordt dit in een vervolgonderzoek te doen. In dit vervolgonderzoek kan ook worden nagegaan of het zin heeft om weegfactoren toe te kennen aan de onderscheiden categorien van het instrument. De praktische bruikbaarheid van de voorgestelde methodiek kan op deze wijze worden vastgesteld en wellicht op onderdelen nog worden verfijnd of verbeterd. De toetsing van het instrument in de praktijk heeft in dit onderzoek opgeleverd dat de normenkaders voor informatiebeveiliging niet worden vastgelegd in de SLAs en ook 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 maken van een Third Party Mededeling (TPM), die betrekking heeft op het niveau van de informatiebeveiliging (conform het VIR 2007) en wordt afgegeven door een onafhankelijke partij.

  • Afstudeerscriptie team 801 blz. 29 van 49

    6 Reflectie

    Algemeen

    Het maken van een scriptie vergt nogal wat. Je moet tijd investeren, werken aan de onderlinge communicatie met elkaar en begeleiders. Lezen van literatuur, het maken van afspraken en het houden van interviews met in eerste instantie soms volstrekt onbekende mensen. Tijdens het totstandkomingproces is ons een aantal dingen opgevallen. Een paar daarvan willen we in dit hoofdstuk met u delen.

    Planning en tijdsduur

    De VU hanteert voor het schrijven van een scriptie een termijn van zes maanden. Als richtlijn voor de studiebelasting wordt 200 uur per persoon aangegeven. Om niet onnodig onder tijdsdruk te komen staan, hebben wij besloten eerder te starten met het schrijven van een scriptie, namelijk in april 2007. Dat is achteraf niet onverstandig gebleken. Het schrijven van een plan van aanpak heeft veel tijd gekost, maar de ervaring is dat wanneer hier goed over nagedacht wordt de tijd wordt terugverdiend in de uitvoeringsfase van het onderzoek. Een langere doorlooptijd dan de geadviseerde termijn is aan te raden om de werkdruk meer te spreiden. Wijziging aanpak

    De initile aanpak voor het onderzoek bleek tijdens de uitvoering van het onderzoek toch niet de aanpak te zijn die zou leiden tot het gewenste resultaat. Deze initile aanpak ging uit van het opstellen van een instrument op basis van de bestudeerde theorie. Dit instrument zou gevalideerd worden in het praktijkonderzoek. Het bleek echter dat de theorie onvoldoende handvatten bood om te komen tot een dergelijk instrument. Daarom hebben wij gekozen de aanpak te wijzigen en op basis van de bestudeerde theorie een vragenlijst op te stellen zodat wij daarmee het praktijkonderzoek konden uitvoeren. Met de informatie vanuit de theorie en verkregen uit het onderzoek hebben wij vervolgens het instrument samengesteld.

    Informatiebeveiliging: een precair onderwerp

    Voordat wij begonnen aan het onderzoek waren wij niet echt bekend met het gekozen onderwerp. Ons onderzoek was in eerste instantie gericht op de beveiligingsaspecten. De aanleiding voor ons was de onderwaardering van het onderwerp beveiliging in een SLA. We hebben ervaren dat dit onderwerp soms gevoelig ligt. In voorkomend geval wilden we bij een sector van een grote rijksoverheidsdienst gesprekken voeren en interviews afnemen. Over beveiliging konden we op papier en in de SLAs niet erg veel terugvinden. Toen bleek dat diverse gesprekspartners enigszins terughoudend werden. De publicatie bij de VU, de veronderstelde mogelijke (politieke) risicos, wellicht de tekortkomingen van de organisatie op dit terrein: het resulteerde er in dat dit deel van het onderzoek voortijdig eindigde. Een aanbeveling die wij willen doen aan toekomstige studenten van de VU: wees alert op mogelijke hindernissen die worden opgeworpen in samenhang met de keuze van het scriptieonderwerp. Je onderzoek kan erop stuklopen. Kies met zorg een onderwerp en een probleemstelling.

  • Afstudeerscriptie team 801 blz. 30 van 49

    Literatuurlijst

    De opgenomen nummers achter de literatuur corresponderen met de voetnoten in de 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, 2002

    Voorschriften/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, 2003

  • Afstudeerscriptie team 801 blz. 31 van 49

    Bijlagen

    Bijlage 1 - aspecten van een SLA

    1. Aandachtspunten Service Level Agreement Waarschuwing: Deze checklist Service Level Agreement is een globale lijst van aandachtspunten die relevant zijn voor het opstellen van een SLA. Er wordt weinig in detail getreden, omdat het toesnijden op iedere individuele praktijksituatie ondoenlijk is. Er kan niet ingegaan worden op de afbreukrisicos die gelopen worden in uw specifieke situatie. Door SLAs moeten juist deze risicos geminimaliseerd worden en vervolgens dienen de allocatie en maatregelen vast gelegd te worden. Deze problematiek is in het geheel niet af te vangen met deze standaardchecklist. Afhankelijk van de situatie waarvoor een SLA opgesteld dient te worden is er meer of minder maatwerk nodig.

    2. Inhoud SLA In dit hoofdstuk zijn de artikelen opgenomen die van belang zijn bij het opstellen van een Service Level Agreement. Aangezien het opstellen van contracten altijd een stukje maatwerk is, kan deze checklist uitsluitend als basis dienen.

    2.1 Identificatie van partijen Beschrijving 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 Uitgangspunten

    2.2.1 Definities en afkortingen Lijst met sluitende en duidelijk gedefinieerde begrippen, afkortingen, formules en meetvoorschriften, die misverstanden helpen voorkomen.

    overzicht van in de SLA gebruikte definities; overzicht van in de SLA gebruikte afkortingen (geen afkortingen van de

    namen van de deelnemende partijen); overzicht van in de SLA gebruikte (algemene) formules en meetvoorschriften; overzicht van in de SLA gebruikte (algemene) tijdstippen van aanvang en

    beindiging aan de hand van meetbare parameters.

    2.2.2 Inleiding en uitgangspunten Plaatsing van inleidende opmerkingen (bijvoorbeeld dat een SLA is opgesteld ter verbetering van de kwaliteit van de dienst) en uitgangspunten (bijvoorbeeld het feit dat personen gerechtigd moeten zijn om de dienst te gebruiken of het niet beschikbaar 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 801 blz. 32 van 49

    2.2.3 Onderwerp van overeenkomst Aangeven op welke dienst (of diensten) de SLA betrekking heeft.

    korte beschrijving van de diensten waar de SLA betrekking op heeft (in relatief grote SLAs) middels een zinsnede als Het verzorgen van ......;

    afsluiting van deze clausule met Het beheren, onderhouden en in standhouden van de hierboven genoemde voorzieningen tegen de in de bijbehorende detailovereenkomsten genoemde prestatiecriteria.

    2.3 Randvoorwaarden

    2.3.1 Aard en omvang van de overeenkomst Beschrijving van de onderdelen waar de dienst betrekking op heeft, zoals de organisaties (en/of bepaalde afdelingen) die de dienst afnemen, de juridische status van de overeenkomst en een verwijzing naar algemeen geldende voorwaarden.

    omvang (geldigheid van de SLA voor delen van de clintorganisatie); juridische status en versie van de SLA; algemene voorwaarden; overige opmerkingen met betrekking tot de aard en de omvang van de

    overeenkomst.

    2.3.2 Beschrijving van de dienst Verwijzing per geleverde dienst naar de betreffende service level specificaties, die opgenomen zijn in de verschillende detailovereenkomsten of bijlagen.

    concrete beschrijving van diensten (verwijzing naar service level specificaties uitgewerkt per dienst);

    servicetijden (normale servicetijden, weekends, feestdagen en vakantiedagen);

    service beschikbaarheid (minimumpercentages, gemiddelde, maximaal aantal verstoringen per periode, meetperiode);

    serviceprestaties. 2.3.3 Afbakening Expliciete beschrijving van de grenzen van de dienstverlening, zowel met betrekking tot de te leveren diensten zelf, als ook tot de hiervoor benodigde middelen.

    afbakenen van de dienst; afbakenen van de automatiseringsmiddelen.

    2.4 Duur en beindiging van de overeenkomst

    Bepaling waarin wordt aangegeven voor welke periode de SLA geldt en hoe de standaardprocedure voor verlenging of beindiging van de SLA luidt.

    duur van de overeenkomst (begin- en einddatum); procedure voor verlenging en beindiging; bijzondere omstandigheden (eventueel met directe beindiging als gevolg).

  • Afstudeerscriptie team 801 blz. 33 van 49

    2.5 Overlegstructuren, contactpersonen en correspondentie

    Vastleggen wanneer gestructureerd overleg plaatsvindt, wie er aan dit overleg zullen deelnemen en wie bij beide partijen verantwoordelijk is voor de onderlinge relatie. Tevens zal een overzicht opgenomen worden van alle contactpersonen en verantwoordelijken bij escalatie of calamiteiten.

    tijdstippen of aanleidingen voor overleg; betrokken personen bij overleg; verantwoordelijke personen voor de onderlinge relatie; overzicht van contactpersonen en verantwoordelijken (inclusief

    telefoonnummers) bij escalatie en/of calamiteiten (meestal een verwijzing naar 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 een verwijzing naar de betreffende bijlage).

    2.6 Eigendom en risico Bepaling van de eigenaar van de apparatuur en programmatuur die nodig is voor het leveren van de dienst, eventueel uitgebreid met een beschrijving van de verantwoordelijk persoon voor achteruitgang of tenietgaan van deze middelen.

    eigenaar van benodigde apparatuur en programmatuur; noemen van organisatie bij wie het risico van tenietgaan of achteruitgang

    van apparatuur en/of programmatuur ligt; opmerkingen over achteruitgang als gevolg van opzet of bewuste

    onzorgvuldigheid.

    2.7 Beveiliging Beveiliging van systemen, services en data zijn belangrijke aspecten. Deze onderdelen dienen dan ook beschermd te worden tegen interne en externe aanvallen.

    procedure van beveiliging van systemen, services, data; maatregelen bij het schenden van beveiligingsprocedures; aanspreekpunt bij beveiligingsincidenten.

    2.8 Rapportage Als opdrachtgever dient u zicht te hebben, te krijgen en te houden op alles wat te maken heeft met het informatiesysteem. Omtrent de rapportage moeten afspraken gemaakt worden betreffende:

    inhoud van de rapportage; verschijningsfrequentie; distributie (functionarissen, afdelingen, etc.).

  • Afstudeerscriptie team 801 blz. 34 van 49

    2.9 Aanpassingen van de SLA

    2.9.1 Wijziging van de dienst Schetsen van mogelijkheden voor het wijzigen van de dienst (zowel door de leverancier als door de afnemer) indien dit noodzakelijk of wenselijk wordt geacht. Tevens wordt beschreven hoe en wanneer wijzigingsverzoeken ingediend kunnen worden en in welke mate het wijzigen van de dienst een herziening van de SLA noodzakelijk maakt. Vast te leggen items zijn:

    wijzigingsprocedure inclusief het noemen van het meldpunt (meestal de helpdesk) 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 SLA Beschrijving van de procedure voor het wijzigen van de SLA en de regeling met betrekking tot de looptijd van de SLA. Bij omvangrijke SLAs loont het tevens de moeite om te beschrijven, wanneer vorige wijzigingen aan de SLA uitgevoerd zijn en wat er destijds gewijzigd is aan de SLA, zodat op eenvoudige wijze terug te zoeken is welke 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 middel

    van berichtgeving of na onderling overleg; vorige wijzigingen en versies van de SLA, inclusief de data waarop de

    verschillende versies in gebruik waren. 2.10 Financile vergoeding

    2.10.1 Prijzen De hoogte van de vergoeding die betaald moet worden dient te worden vastgelegd, inclusief grenzen aan stijgingen. Hierdoor krijgt de opdrachtgever zekerheid 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 prijsstijgingen

    conform consumenten prijsindex cijfer van CBS. 2.10.2 Betaling Afspraken aangaande betaling van overeengekomen vergoedingen dienen te worden vastgelegd om onduidelijkheden en/of problemen hieromtrent te voorkomen. 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 801 blz. 35 van 49

    2.11 Verantwoordelijkheid, escalatie en reclame

    2.11.1 Verantwoordelijkheid, aansprakelijkheid en strafbepalingen Vermelding van zowel de aansprakelijkheid voor de bij de clintorganisatie opgestelde apparatuur en/of programmatuur als van de aansprakelijkheid van de leveranciersorganisatie voor het functioneren van de clintorganisatie.

    aansprakelijkheid van leveranciersorganisatie voor functioneren van clintorganisatie, bijvoorbeeld in geval van storingen of calamiteiten;

    gevolgen van het niet (volledig) nakomen van afspraken; verhalen van schade als gevolg van een onvoldoende functionerende

    dienst; beschrijving van overleg in geval van problemen (eventueel het verwijzen

    naar de clausule over geschillen); boeteclausules of andere financile strafbepalingen.

    2.11.2 Beperkingen, afhankelijkheden en overmacht Vastlegging van beperkingen met betrekking tot het gebruik van de te leveren diensten, de afhankelijkheid van derde organisaties (bijvoorbeeld KPN t.b.v. communicatie) en het schetsen van situaties waarin de organisaties zich kunnen beroepen op overmacht.

    maximaal aantal gelijktijdige gebruikers van de verschillende diensten; maximaal aantal toegelaten gebruikers (maximaal aantal accounts) van

    de verschillende diensten; afhankelijkheid van andere organisaties of diensten; regeling met betrekking tot het beroepen op overmacht, inclusief de

    mogelijkheid tot het buiten werking stellen van de SLA en de te ondernemen acties om zo spoedig mogelijk terug te kunnen keren naar de normale situatie;

    algemene calamiteitenprocedure, inclusief een verwijzing naar de verschillende calamiteitenplannen;

    overige beperkingen (bijvoorbeeld het maximaal aantal transacties per periode).

    2.11.3 Geheimhouding, verantwoordelijkheid en concurrentiebeding Afspraken met betrekking tot het niet openbaar maken of aan derden beschikbaar stellen van vernomen informatie tijdens het opstellen van de SLA (inhoudelijke SLA-bepalingen) of het functioneren van de dienst (informatie verkregen door database-opvragingen dient als vertrouwelijk te worden aangemerkt). Tevens kunnen bepalingen worden opgenomen voor bescherming tegen het overnemen van personeel (concurrentiebeding) of het rechtstreeks onderhandelen van de clintorganisatie (buiten de leverancier om) met derden over de levering van (delen van) diensten.

    afspraken met betrekking tot geheime of vertrouwelijke informatie; concurrentiebeding, bijvoorbeeld aangaande het overnemen van personeel.

  • Afstudeerscriptie team 801 blz. 36 van 49

    2.11.4 Geschillen Beschrijving van het feit wanneer onderling overleg plaatsvindt en wat de procedure is bij het optreden van onderlinge conflicten of geschillen qua afhandeling en het betrekken 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 handtekeningen Formele afsluiting van de SLA, waarin gesteld wordt dat de betrokken partijen het bovenstaande overeengekomen zijn ondertekend door verantwoordelijke personen uit beide organisaties.

    formele afsluiting; namen en handtekeningen van tekengerechtigde personen.

  • Afstudeerscriptie team 801 blz. 37 van 49

    Bijlage 2 - VIR 2007, Code voor Informatiebeveiliging, Cobit en ITIL

    Inleiding Rijksoverheid De Rijksoverheid gebruikt als referentiekader het Voorschrift Informatie Voorziening 2007(VIR). In de toelichting op het VIR worden o.a. de volgende punten aangegeven, die overheidsdiensten dwingen om aandacht te besteden aan informatiebeveiliging: Het gebruik van computers en datacommunicatie is binnen de rijksdienst

    gemeengoed geworden. Veel routinematige processen verlopen geautomatiseerd en op praktisch iedere werkplek staat een computer of terminal. Dat verhoogt de productiviteit van de Rijksdienst. De kwaliteit van de bijbehorende werkprocessen wordt steeds meer bepaald door de kwaliteit van de hulpmiddelen die de informatietechnologie biedt.

    Informatiebeveiliging is een essentieel onderdeel van die kwaliteit. Integriteit, exclusiviteit en beschikbaarheid van informatie en informatiesystemen zijn in hoge mate bepalend voor de kwaliteit van de werkprocessen binnen de Rijksdienst.

    Systemen die alleen financile gegevens bevatten zijn in de minderheid, veelal zullen in zo'n systeem ook persoonsgegevens zitten of is het sy