Download - ‘Toetsingskader voor IV-dienstverlening binnen de ... · ‘Toetsingskader voor IV-dienstverlening binnen de Rijksoverheid’ - nut en noodzaak van een SLA - postgraduate IT-opleiding

‘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


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 open 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, collega’s 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


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 (SLA’s). 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 SLA’s 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 SLA’s 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.


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 SLA’s 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


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.


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




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


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 essentiële

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.


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 geïnterviewd. 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 geïnterviewde ter becommentariëring. 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)


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 SLA’s

en beveiliging in een overheidsomgeving

H3 Bevindingen praktijkonderzoek

H4 Auditinstrument

H5 Conclusies en aanbevelingen

H6 Reflectie


2 Theoretisch kader SLA’s 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 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 en vastgelegd.


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 middelen 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


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 georiënteerd 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, SLE’s) worden vastgelegd 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 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 wèl 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 gecreëerd 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


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. Eén 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 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 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 SLA’s 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.


Onderstaande figuur geeft de indeling naar de verschillende soorten en categorieën SLA’s weer:

Figuur 3: indeling soorten en categorieën SLA’s

(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 SLA’s 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


� Het bindende karakter van de SLA

SLA’s kunnen worden onderscheiden in adviserende en contractuele SLA’s. Voor beide SLA’s geldt dat zij ondersteuning bieden bij de beheersing van de verwachtingen van de gebruikersorganisatie. Een kenmerkend verschil is dat bij adviserende SLA’s geen financiële sancties worden opgenomen. Contractuele SLA’s 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 SLA’s met boetebepalingen. De Rijksoverheid vormt immers één rechtspersoon. Interdepartementale SLA’s bevatten derhalve zelden financiële boetebepalingen. Het gevolg van het ontbreken van financiële 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 definiëren van de noodzakelijke processen die nodig zijn om de behoeften en wensen van de gebruikersorganisatie te kunnen vervullen; (het efficiënt 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)


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 serviceorganisatie 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


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 SLA’s 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 weten 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)


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 SLA’s: 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)


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 geïnterviewden. 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 geïnterviewden 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 risico’s een belangrijk doel is van een SLA.


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 risico’s. De risico’s 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 financiële en/of reputatieschade lijdt. De IT-serviceorganisatie kan eveneens reputatieschade lijden en bij uitbesteding ook financiële schade lijden als er sprake is van boetebepalingen. Ontwikkelen van een SLA

Uit de interviews is gebleken dat alle gebruikte SLA’s 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.


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 SLA’s 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 SLA’s 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.


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 SLA’s. 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 geïnterpreteerd. 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 definiëren 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 SLA’s wordt niet vastgelegd welk normenkader wordt gehanteerd in relatie tot de informatiebeveiliging.


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 SLA’s 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.


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 essentiële

onderwerpen 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 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.


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 vóór 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 SLA’s. 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 hoofdcategorieën. Deze hoofdcategorieën 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, subcategorieën 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.


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 categorieën. 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.


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




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 subcategorieën 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 categorieën 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 categorieën 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 SLA’s 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.


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 initiële 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 initiële 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 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 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.


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


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 afbreukrisico’s die gelopen worden in uw specifieke situatie. Door SLA’s moeten juist deze risico’s 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

beëindiging 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.


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 SLA’s) 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 cliëntorganisatie); • 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 beëindiging van de overeenkomst

Bepaling waarin wordt aangegeven voor welke periode de SLA geldt en hoe de standaardprocedure 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).


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.).


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 SLA’s 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 Financiële 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.


2.11 Verantwoordelijkheid, escalatie en reclame

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

• aansprakelijkheid van leveranciersorganisatie voor functioneren van cliëntorganisatie, 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 financiële 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 cliëntorganisatie (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.


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.


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 financiële gegevens bevatten zijn in de minderheid, veelal zullen in zo'n systeem ook persoonsgegevens zitten of is het systeem van dusdanig belang dat de beschikbaarheid ervan bijzondere aandacht behoeft. De verschillende regimes die of uitgaan van het soort gegeven dat beveiligd dient te worden of van de handeling die beschermd dient te worden (denk aan opslag, verwerking en overdracht) overlappen elkaar steeds meer. Het is daarom alleen al vanuit praktisch oogpunt gewenst dat er een kader bestaat voor de rijksdienst, waarbinnen systematisch en vergelijkbaar met alle aspecten van informatiebeveiliging wordt omgegaan. Zo'n kader is neergelegd in de vernieuwde regelgeving voor informatiebeveiliging.

� De overheid dient op een betrouwbare manier om te gaan met gegevens van burgers en bedrijfsleven. Ze is daarbij afhankelijk van informatietechnologie. Voor een deel vloeit de noodzaak tot betrouwbaarheid voort uit weten regelgeving. De voortschrijdende ontwikkeling van de informatietechnologie en de inzet daarvan noodzaken tot voortdurende bezinning. Afwegingen met betrekking tot de inzet van informatietechnologie en de organisatie daarvan dienen vastgelegd te worden, ook vanuit de optiek van integriteit, exclusiviteit en beschikbaarheid.

� De naleving van beveiligingsmaatregelen die op basis van genoemde afwegingen plaatsvindt, dient controleerbaar te zijn. Dat is voor de hele overheid als maatschappelijke partij van belang maar zeker ook voor de individuele organisatie. Bij gebruik van gegevens van derden bijvoorbeeld, dient van het begin af aan duidelijk te zijn hoe met vervuiling van die gegevens wordt omgegaan. Informatietechnologie kan de efficiëntie van de rijksdienst verhogen maar dient niet ten koste te gaan van de positie van de burger. Goede afspraken bij het koppelen van bestanden zijn daarom nodig.


VIR 2007 en beveiliging

Bij systemen die onderdeel zijn van een keten, maakt het lijnmanagement via een Service 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 van beveiliging binnen een organisatie. Hiermee wordt een garantie afgegeven dat de andere organisatie in de keten voldoet 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 de eigenaar van het informatiesysteem (uiteindelijk lijnmanagement) en de IT dienstenleverancier. Beschikbaarheid is meer en meer het werkterrein van de beheerder en wordt vooral met techniek gerealiseerd. De beheerder is verantwoordelijk voor het correct en beheerst uitvoeren van de afspraken uit de SLA en rapporteert hierover aan de opdrachtgever. Voor de informatiebeveiligingsfunctie rest vooral het toezicht op de maatregelen die waarborgen, dat informatie niet verloren gaat, indien zich ernstige problemen voordoen. Code voor Informatiebeveiliging BS 7799-1:2000

In de CvI wordt alleen gesproken over de contracten die behoren bij outsourcing en de bijbehorende beveiligingseisen: De beveiligingseisen van een organisatie die het beheer van een deel of alle informatiesystemen, netwerken en/of desktopomgevingen uitbesteedt, dienen in een 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 de gebruikersorganisatie zijn geborgd;

� welke fysieke en logische beheersmaatregelen m.b.t. gevoelige informatie zijn getroffen;

� beschikbaarheid van de services in geval van een calamiteit; � welke niveaus van fysieke beveiliging worden geleverd; � het recht om te auditen


ITIL Security Management

ITIL is een publicatie van de “beste praktijkoplossingen” op het gebied van beheer van Informatie Technologie. Het geeft richtlijnen hoe een IT-serviceorganisatie het best kan garanderen dat haar klanten de producten en diensten krijgen die zij verlangen. Het doel van ITIL is meer grip te krijgen op de kwaliteit van de IT-dienstverlening. Het beoogt een kwaliteitssysteem te zijn voor het beheren van de IT-infrastructuur. ITIL beschrijft processen, die bij een adequate implementatie de kwaliteit van de dienstverlening voor de afnemers zeker stelt. Er moet echter wel aan de volgende randvoorwaarden worden voldaan: � omdat ITIL uitsluitend logische procesbeschrijvingen geeft, maar niet ingaat op

de aspecten als het beleggen van verantwoordelijkheden en criteria voor de inrichting, stelt dit hoge eisen aan de inrichting van de organisatie en de sizing van ITIL, om het tot een werkend en vooral werkbare systematiek te vormen;

� ITIL beperkt zich tot het beschrijven van de beheerprocessen. Uitvoerende IT-taken worden niet beschreven en ook de beheerprocessen aan de gebruikerskant komen niet aan de orde.

Het basisprincipe van ITIL is, dat de IT service organisaties diensten levert aan de afnemer (gebruikersorganisatie) tegen gerechtvaardigde kosten. ITIL geeft geen harde koppeling tussen de te verlenen diensten en de vergoeding die hiervoor gegeven 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 beheerprocessen De tactische processen zorgen in overleg met de klant voor een detaillering van afspraken en de plannen die nodig zijn voor de IT-dienstverlening. Service level management is een belangrijk proces op tactisch niveau. Beveiliging en beheer

Organisaties zijn voor het functioneren steeds sterker afhankelijk van IT. Daarom moeten eisen worden gesteld aan informatiebeveiliging. Deze eisen worden opgelegd aan de aanbieder van IT-diensten. De SLA is hiervoor een goed communicatiekanaal. Het ITIL proces Security Management geeft de structurele inpassing van beveiliging in de beheerorganisatie en zorgt ervoor dat de dienstverlening op beveiligingsgebied op het met de klanten afgesproken niveau blijvend worden geboden. Beveiliging en beheer zijn onafscheidbaar. Zonder een goed ingericht beheer is beveiliging niet mogelijk en vice versa. Het ITIL Security Management is mede gebaseerd op de Code voor Informatiebeveiliging.


In ITIL wordt het perspectief gekozen van de IT-serviceorganisaties. Het doel van het proces Security Management is tweeledig: 1) het realiseren van de beveiligingseisen in de (verschillende) SLA’s en andere

externe vereisten in andere contracten, wetgeving en eventueel intern of extern opgelegd beleid.

2) Het realiseren van een basisniveau aan beveiliging. Dit is nodig om de eigen continuïteit van de beheerorganisatie te waarborgen, maar ook om te komen tot een vereenvoudiging van het SLM voor informatiebeveiliging. Het beheer van een groot aantal verschillende SLA’s is complexer dan een beperkt aantal.

Het proces Security Management heeft relaties met de meeste andere ITIL-processen. In de andere processen moeten namelijk activiteiten plaatsvinden ten behoeve van beveiliging. De ITIL processen zijn tot op zekere hoogte toe te wijzen aan de drie besturingslagen die in organisaties kunnen worden herkend. In de bovenste laag wordt de strategie van het beheer uitgestippeld. Voor informatiebeveiliging is deze vooral van belang waar het de organisatie van de beheerorganisatie betreft. De middelste laag (tactiek) bevinden zich de Service Delivery processen. Deze processen zorgen voor het opstellen van SLA’s en die de dienstverlening verzorgen conform de afspraken in deze SLA’s. De beveiligingsafspraken worden ook in de SLA’s vastgelegd. Het proces Security Management bevindt zich ook in deze laag. Dit proces heeft relaties met de andere 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 de Service Support processen te vinden. De Service Support processen verzorgen het daadwerkelijk operationeel beheer van IT-middelen zelf. Het proces Security Management is afhankelijk van deze processen omdat deze voorwaardenscheppend zijn. In de SLA worden afspraken tussen de IT-serviceorganisatie en de gebruikersorganisatie vastgelegd. De SLA is de verantwoordelijkheid van het Service Level Management en fungeert als belangrijkste sturingsinformatie voor de ITIL-processen. Beveiligingsparagraaf in de SLA

De totstandkoming van de beveiligingsparagraaf in de SLA begint bij de beveiligingsbehoefte van de klant. De klant geeft uitdrukking aan de belangen van zijn bedrijfsprocessen. Deze bedrijfsprocessen zijn afhankelijk van IT en daarom van de IT-beheerorganisatie. Hoe de beveiligingsbehoefte moet worden bepaald vormt geen 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 van de IT-serviceorganisatie treden hierover in onderhandeling. De IT-serviceorganisatie legt zijn standaard aanbod (vastgelegd in een Service Catalogus) naast de door de klant gedefinieerde service level requirements. In de Service Catalogus is het basisniveau van beveiliging ofwel security baseline weergegeven.


De klant en de accountmanager stellen samen vast hoe de service level requirements 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 diensten die aan gebruikersorganisaties (klanten) worden geleverd. Het doel is te komen tot een optimaal niveau van IT-dienstverlening. SLM onderscheidt een aantal samenhangende beveiligingsactiviteiten waarin Security Management een belangrijke rol speelt: � identificatie van de beveiligingsbehoefte van de klant (het vaststellen van de

beveiligingsbehoefte blijft de verantwoordelijkheid van de klant zelf omdat deze behoefte voortkomt uit zijn bedrijfsbelangen);

� verifiëren van de haalbaarheid van deze beveiligingsbehoefte van de klant; � voorstellen doen voor, onderhandelen over en vastleggen van het gewenste

beveiligingsniveau van de IT-diensten in de SLA; � doen bepalen, opstellen en vastleggen van interne beveiligingsnormen voor de

IT-dienstverlening; � doen bewaken van die beveiligingsnormen; � rapporteren over geleverde IT-diensten. Voor de eerste drie activiteiten levert Security Management input en ondersteuning aan SLM. Activiteiten vier en vijf worden uitgevoerd door Security Management. Voor activiteit zes levert onder andere Security Management input. De daadwerkelijke uitvoering van de werkzaamheden is een kwestie van overleg tussen de SLM en de SM.


Bijlage 3 - gehanteerde gestructureerde vragenlijst

De 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 uw

werkzaamheden? 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 het

opstellen van een SLA? 10. Hoe wordt een team samengesteld? 11. Maakt u gebruik van een standaard SLA of wordt deze iedere keer opnieuw

opgesteld? 12. Welk normenkader/referentiekader wordt gehanteerd bij het opstellen van een

SLA? 13. Waarom wordt dat specifieke normenkader/referentiekader gebruikt? 14. Hoe komt de inhoud van de overeenkomst tot stand? (zie bijlage 1 met

standaard onderwerpen SLA) 15. Waarom zijn juist de genoemde elementen in de SLA opgenomen en geen

andere elementen? 16. Zijn er ontbrekende elementen welke nog zouden moeten worden toegevoegd?

(bijv. calamiteitenplan) 17. Hoe lang duurt de totstandkoming van een gemiddeld SLA? (doorlooptijd

proces) 18. Wat is de werkelijke tijdsbesteding bij de totstandkoming geweest? (feitelijke

tijdsbesteding bijv in uren/dagen) 19. Welke afspraken worden gemaakt m.b.t. het beheer van de SLA; evaluatie van

SLA en tijdstippen voor herziening? (alleen stellen als er niets over is opgenomen in de SLA)


c) Testen (interpretatie door verschillende partijen)

20. Wordt een concept SLA voorgelegd bij de betrokken partijen voordat deze definitief gemaakt wordt?

21. Welke criteria worden gehanteerd bij het ‘testen’? 22. Wordt er met de verschillende partijen gesproken over de inhoud van het

concept SLA? d) Gebruik van de SLA

23. 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 bij

de gebruikers? Zo ja, op welke wijze? 26. Worden sancties toegepast bij het niet nakomen van de overeengekomen

afspraken? 27. Wat zijn de sterke en zwakke punten van het gebruik van een SLA? e) Evaluatie werking SLA en eventueel herziening 28. 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 gebruik

33. Hoe vindt de beëindiging plaats? 34. Wie neemt de beslissing(en) daarover? • Procesrollen 35. Welke rollen onderscheidt u in de verschillende fasen van de lifecycle van een

SLA? 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 van

de SLA belegd? 39. Is dit functieniveau bepalend of controlerend of adviserend? 40. Worden bevoegdheden en verantwoordelijkheden gemandateerd of

gedelegeerd? 41. Door wie worden de go/no go beslissingen genomen in het

totstandkomingsproces 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)


Inhoud specifiek m.b.t. beveiliging

46. 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? (na

dit gecheckt te hebben in de SLA)

• Afsluiting 56. Heeft u nog aanvullende op- of aanmerkingen?


Bijlage 4 - het Auditinstrument

Onderstaand is het instrument weergegeven dat is besproken in hoofdstuk 4 van de scriptie. Als inleiding hierop zal een korte gebruikshandleiding worden beschreven. Gebruikershandleiding

Om aan de slag te gaan met het instrument moeten allereerst afspraken gemaakt worden met de juiste personen van de gebruikersorganisatie en de juiste personen van de IT-serviceorganisatie. Het is zinvol de relevante informatie en documentatie op te vragen en door te nemen voordat de interviews plaatsvinden. De opgenomen vragen in de tabel en de aanvullende vragen onder de tabel dienen als leidraad voor de interviews. Auditinstrument

Hoofdcategorie Subcategorie Aandachtspunten inclusief te stellen vragen Antwoord

Doelen Is het doel van de SLA bekend bij de betrokken partijen?

J/N

Randvoorwaarden en uitgangspunten

Zijn er uitgangspunten en randvoorwaarden opgenomen in de SLA?

J/N

Algemeen

Rechten en plichten Zijn de rechten en plichten van zowel de gebruikersorganisatie als de IT-serviceorganisatie in de SLA opgenomen?

J/N

Aanleiding totstandkoming SLA

Is er nagedacht over de risico’s die met de SLA moeten worden gemitigeerd?

J/N

Ontwikkelen Is er voor de totstandkoming van de SLA een team samengesteld?

J/N

Testen Is er een testprocedure – vóór ingebruikname van de SLA – beschreven?

J/N

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

Lifecycle SLA

Evaluatie van de SLA Wordt er gerapporteerd over de realisatie van de overeengekomen afspraken in de SLA? Vinden er gesprekken plaats naar aanleiding van de rapportages? Worden er ook wijzigingen doorgevoerd in de afspraken?

J/N J/N J/N

Bedrijfsdoelstellingen

Is er in de SLA een relatie gelegd met de bedrijfsdoelstellingen van de gebruikersorganisatie?

J/N

Samenstellen SLA

Is er voor het opstellen van een SLA een template gebruikt? Is geborgd dat alle relevante afspraken/servicelevels zijn opgenomen in de SLA?

J/N J/N

Inhoud van een

SLA (algemeen)

Kwaliteitsniveau

Zijn alle afspraken/servicelevels in de SLA concreet en meetbaar?

J/N


Begrip ‘Beveiliging’ Is het begrip beveiliging in de SLA beschreven? Is het begrip voor beide partijen helder? Zijn de rechten en plichten van beide partijen m.b.t. beveiliging opgenomen?

J/N J/N J/N

Referentiekaders Is gebruik gemaakt van een algemeen aanvaard normenkader voor het opstellen van de SLA? Zijn er afspraken gemaakt over het te hanteren normenkader informatiebeveiliging? Zijn er afspraken gemaakt over de aantoonbare naleving van dat normenkader (TPM)?

J/N J/N J/N

Regelgeving Is er rekening gehouden met de geldende regelgeving betreffende het onderwerp beveiliging (VIR)?

J/N

Inhoud van een

SLA (beveiliging)

Incidenten Zijn er afspraken in de SLA vastgelegd over hoe om te gaan met beveiligingsincidenten?

J/N


Vragenlijst ter verdieping en/of aanvulling van de bovengenoemde onderwerpen

Hieronder zijn de aanvullende vragen opgenomen. De indeling komt overeen met de in de tabel opgenomen onderwerpen. Achter sommige vragen is tussen haakjes een verwijzing opgenomen naar het corresponderende nummer van een vraag uit de door ons gehanteerde vragenlijst in het onderzoek.

Doelen Een 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 uitgangspunten Een 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 plichten Rechten en plichten zijn onlosmakelijk verbonden aan de levering van diensten door

de ene partij aan de andere

7) 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 zijn opgenomen in de SLA? Aanleiding totstandkoming SLA Een 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) Ontwikkelen

Het opstellen van een SLA vereist het samenstellen van een team waarin de juiste

personen 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 de gebruikersorganisatie en IT-serviceorganisatie wel betrokken bij de totstandkoming van 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?


Samenstellen SLA

Het gebruik maken van een standaard sjabloon als uitgangspunt kan voorkomen

dat relevante onderwerpen worden vergeten.

16) Indien er geen gebruik wordt gemaakt van een standaard, hoe worden dan de onderwerpen bepaald die worden opgenomen in de SLA? 17) Hoe wordt de volledigheid van de minimaal vast te leggen onderdelen gewaarborgd? Testen De interpretatie van afspraken in de ‘definitieve’ SLA dient voor beide partijen gelijk

te zijn.

18) Worden conceptversies van SLA’s uitgewisseld tussen beide partijen? (nr. 20) 19) Bestaan er testcriteria voor de beoordeling van het gewenste kwaliteitsniveau van een SLA? (nr. 21) 20) Wat zijn de gehanteerde testcriteria? (nr. 21) Gebruik van de SLA Een SLA dient door beide partijen te worden goedgekeurd en ondertekend.

21) Indien de SLA niet door de betrokken partijen is ondertekend, waarom is dit niet het 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 van

overeengekomen 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 betreft het? 27) Zijn de eventuele sancties goed toepasbaar? Evaluatie van de SLA

Periodieke evaluaties zijn nodig om vast te stellen of een SLA ook werkt zoals is

bedoeld.

28) Is vastgelegd hoe vaak er gerapporteerd moet worden over de werking van de SLA? (nr. 28) 29) Vindt er daadwerkelijk overleg plaats tussen de gebruikersorganisatie en IT-serviceorganisatie over de geleverde rapportages? (nr. 29) 30) Welke functionarissen zijn betrokken bij de evaluatie? (nr. 30) Bedrijfsdoelstellingen De bedrijfsdoelstellingen zijn in hoge mate bepalend voor de concrete uitwerking

ervan 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? Kwaliteitsniveau

Om een zeker kwaliteitsniveau te kunnen behalen, is het van belang dat afspraken

en serviceniveaus meetbaar zijn gemaakt.


32) Als er geen concrete vertaling is gemaakt naar meetbare eenheden, hoe wordt dan vastgesteld of de afspraken naar behoren zijn nagekomen? Beveiliging en SLA Informatiebeveiliging is een belangrijk onderdeel van de afspraken en dus ook van

de 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 onderwerp beveiliging 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 de beveiligingsparagraaf? Referentiekaders Referentiekaders zijn zeer bruikbare hulpmiddelen bij het opstellen van een SLA

38) Indien geen gebruik wordt gemaakt van algemeen aanvaarde kaders, aan welke richtlijnen worden dan gerefereerd? Regelgeving Naast verplichte regelgeving kunnen er ook bedrijfsinterne richtlijnen zijn opgesteld

waarin het onderwerp beveiliging is opgenomen.

39) Voorzien de interne richtlijnen wel in het afdekken van beveiligingsrisico’s? Incidenten De wijze waarop wordt omgegaan met beveiligingsincidenten zegt iets over de

risico’s die worden gelopen en de mate waarin de getroffen maatregelen effectief

zijn.

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)