voorbeeld service level agreement (sla) met aandacht voor ...

66
VOORBEELD SERVICE LEVEL AGREEMENT (SLA) MET AANDACHT VOOR INFORMATIEBEVEILIGING Een van de producten van de operationele variant van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)

Transcript of voorbeeld service level agreement (sla) met aandacht voor ...

Page 1: voorbeeld service level agreement (sla) met aandacht voor ...

VOORBEELD SERVICE LEVEL AGREEMENT (SLA) MET AANDACHT VOOR INFORMATIEBEVEILIGING Een van de producten van de operationele variant van de Baseline

Informatiebeveiliging Nederlandse Gemeenten (BIG)

Page 2: voorbeeld service level agreement (sla) met aandacht voor ...

2

Colofon

Naam document

Voorbeeld Service Level Agreement (SLA) met aandacht voor informatiebeveiliging

Versienummer

1.0.1

Versiedatum

Augustus 2016

Versiebeheer

Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD).

Copyright

© 2016 Kwaliteitsinstituut Nederlandse Gemeenten (KING).

Alle rechten voorbehouden. Verveelvoudiging, verspreiding en gebruik van deze uitgave voor het

doel zoals vermeld in deze uitgave is met bronvermelding toegestaan voor alle gemeenten en

overheidsorganisaties.

Voor commerciële organisaties wordt hierbij toestemming verleend om dit document te bekijken, af

te drukken, te verspreiden en te gebruiken onder de hiernavolgende voorwaarden:

1. KING wordt als bron vermeld;

2. Het document en de inhoud mogen commercieel niet geëxploiteerd worden;

3. Publicaties of informatie waarvan de intellectuele eigendomsrechten niet bij de verstrekker

berusten, blijven onderworpen aan de beperkingen opgelegd door KING;

4. Iedere kopie van dit document, of een gedeelte daarvan, dient te zijn voorzien van de in deze

paragraaf vermelde mededeling.

Rechten en vrijwaring

KING is zich bewust van haar verantwoordelijkheid een zo betrouwbaar mogelijke uitgave te

verzorgen. Niettemin kan KING geen aansprakelijkheid aanvaarden voor eventueel in deze uitgave

voorkomende onjuistheden, onvolledigheden of nalatigheden. KING aanvaardt ook geen

aansprakelijkheid voor enig gebruik van voorliggende uitgave of schade ontstaan door de inhoud

van de uitgave of door de toepassing ervan.

Met dank aan

De expertgroep en de reviewgemeenten die hebben bijgedragen aan het vervaardigen van dit

product.

Wijzigingshistorie

Versie Datum Opmerkingen

1 Juli 2015

1.0.1 Augustus 2016

Taskforce BID verwijderd, WBP vervangen door Wbp, GBA vervangen door BRP

Page 3: voorbeeld service level agreement (sla) met aandacht voor ...

3

Voorwoord

De IBD is een gezamenlijk initiatief van de Vereniging van Nederlandse Gemeenten (VNG) en het

Kwaliteitsinstituut Nederlandse Gemeenten (KING) en actief sinds 1 januari 2013. Aanleiding voor

de oprichting van de IBD vormen enerzijds de leerpunten uit een aantal grote incidenten op

informatiebeveiligingsvlak en anderzijds de visie Digitale Overheid 2017.

De IBD is er voor alle gemeenten en richt zich op bewustwording en concrete ondersteuning om

gemeenten te helpen hun informatiebeveiliging naar een hoger plan te tillen.

De IBD heeft drie doelen:

1. Het preventief en structureel ondersteunen van gemeenten bij het opbouwen en onderhouden

van bewustzijn als het gaat om informatiebeveiliging.

2. Het leveren van integrale coördinatie en concrete ondersteuning op gemeente specifieke

aspecten in geval van incidenten en crisissituaties op het vlak van informatiebeveiliging.

3. Het bieden van gerichte projectmatige ondersteuning op deelgebieden om informatiebeveiliging

in de praktijk van alle dag naar een hoger plan te tillen. De ondersteuning die de IBD biedt bij

het ICT-Beveiligingsassessment DigiD is een voorbeeld van een dergelijk project.

Hoe realiseert de IBD haar doelen?

Om invulling te kunnen geven aan haar doelen is door de IBD op basis van de Baseline

Informatiebeveiliging Rijksdienst (BIR) een vertaalslag gemaakt naar een baseline voor de

gemeentelijke markt. Deze Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) betreft

twee varianten, een Strategische- én een Tactische Baseline. Beide varianten van de BIG zijn

beschikbaar voor alle gemeenten op de website en community van de IBD, zodat door iedere

gemeente tot implementatie van de BIG kan worden overgegaan. Bestuur en management hebben

met deze baseline een instrument in handen waarmee zij in staat zijn om te meten of de

organisatie ‘in control’ is op het gebied van informatiebeveiliging. Om de implementatie van de

Strategische en Tactische Baseline te ondersteunen, zijn door de IBD producten ontwikkeld op

operationeel niveau. Dit heeft een productenportfolio opgeleverd, genaamd de Operationele

Baseline Nederlandse Gemeenten.

Naast een productenportfolio, heeft de IBD voor gemeenten ook een dienstenportfolio ontwikkeld.

Voor een volledig overzicht van het producten- en dienstenportfolio, kunt u terecht op de website

van de IBD.

De gemeente is zelf verantwoordelijk voor het opstellen en/of uitvoeren en/of handhaven van de

regels. Hierbij geldt:

- Er is wetgeving waar altijd aan voldaan moet worden, zoals niet uitputtend: BRP, SUWI, BAG,

PUN en Wbp, maar ook de archiefwet.

- Er is een gemeenschappelijk normenkader als basis: de Baseline Informatiebeveiliging

Nederlandse Gemeenten (BIG).

- De gemeente stelt dit normenkader vast, waarbij er ruimte is in de naleving van dat kader voor

afweging en prioritering op basis van het ‘pas toe of leg uit’ principe.

Page 4: voorbeeld service level agreement (sla) met aandacht voor ...

4

Leeswijzer

Dit product maakt onderdeel uit van de operationele variant van de Baseline Informatiebeveiliging

Nederlandse Gemeenten (BIG).

Doel

Het doel van dit document is het leveren van een voorbeeld Service Level Agreement (SLA). Dit

voorbeeld bevat een template en voorbeelduitwerkingen die kunnen worden gebruikt bij het

opstellen en/of reviewen van een SLA om te verifiëren of alle relevante aspecten zijn beschreven.

Doelgroep

Dit document is van belang voor het management van de gemeente, de systeemeigenaren,

applicatiebeheerders en de ICT-afdeling.

Leesadvies

Dit document bevat een template met een globale lijst met aandachtspunten die relevant zijn bij

het opstellen van een Service Level Agreement (SLA) met concrete voorbeelduitwerkingen. Het

toesnijden op iedere gemeentelijke individuele praktijksituatie is ondoenlijk en er kan dan ook niet

ingegaan worden op het afbreukrisico’s die in uw specifieke situatie gelopen wordt. Op basis van

het af te nemen product en/of dienst en een eigen risicoafweging, dient de gemeente te beslissen

welke onderdelen uit deze template relevant zijn. Deze relevante onderwerpen kunnen daarna door

de gemeente gebruikt worden om de nieuwe SLA op te stellen of de SLA van de dienstleverancier

te beoordelen.

Relatie met overige producten

Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)

o Strategische variant van de Baseline Informatiebeveiliging voor Gemeenten

o Tactische variant van de Baseline Informatiebeveiliging voor Gemeenten

Informatiebeveiligingsbeleid van de gemeente

Maatregelen tactische variant Baseline Informatiebeveiliging Nederlandse Gemeenten

(BIG)

6.2.1 : Identificatie van risico's die betrekking hebben op externe partijen

6.2.3 : Beveiliging behandelen in overeenkomsten met een derde partij

7.1.2 : Eigendom van bedrijfsmiddelen

8.1.1 : Rollen en verantwoordelijkheden

10.2 : Dienstverlening en Controle en beoordeling van dienstverlening door een derde partij

15 : Naleving

Page 5: voorbeeld service level agreement (sla) met aandacht voor ...

5

Inhoud

i. Versiebeheer/Wijzigingshistorie 7

ii. Distributielijst 8

iii. Leeswijzer 9

0 Positie SLA en gerelateerde documenten 10

1 Inleiding 11 1.1 Doel van de SLA 12

1.2 Vastlegging van partijen en goedkeuring 12

1.3 Ingangs- en einddatum 13

2 Governance 14 2.1 Verlenging en beëindiging 14

2.2 Ontbinding en garanties 15

2.3 Wijzigingsbeheer 15

3 Dienstverlening, doelen en resultaten 17 3.1 Dienstverlening 17

3.2 Gebruiksresultaat 18

3.3 Garanties 18

3.4 Kwaliteit 19

3.5 Dienstverleningstijden 19

3.6 On-site ondersteuning 23

3.7 Ondersteuning op afstand 24

3.8 Eigendom 25

4 Communicatie tussen gemeente en dienstverlener 26 4.1 Verantwoordelijke contactpersoon gemeente 26

4.2 Verantwoordelijk (klant) manager leverancier 26

4.3 Dienstrapportages 27

4.4 Uitzonderingen en klachten 27

4.5 Tevredenheidonderzoeken 28

4.6 Servicebeoordelingen 28

4.7 Geheimhouding, verantwoordelijkheid en concurrentiebeding 28

5 Dienstenniveau eisen / doelen 29 5.1 Beschikbaarheidsdoelstellingen 29

5.2 Capaciteit / prestatiedoelstellingen en garanties 33

5.3 Continuïteitseisen 36

5.4 Beveiligingseisen 36

5.5 Databeheer 43

5.6 Bescherming persoonsgegevens 47

5.7 Performanceniveau 52

6 Taken en verantwoordelijkheden 54 6.1 Plichten van de dienstverlener 54

6.2 Plichten van de gemeente 56

6.3 Verantwoordelijkheden gebruikers 56

6.4 Monitoring van beveiligingseisen 56

6.5 Addendum informatiebeveiligingsdienst voor gemeenten 57

6.6 Beperkingen, afhankelijkheden en overmacht 57

Page 6: voorbeeld service level agreement (sla) met aandacht voor ...

6

6.7 Aansprakelijkheden 57

7 Kosten 58 7.1 Kosten dienstverlening 58

7.2 Sancties, bonussen 59

8 Verklarende voordenlijst 60 8.1 Definities 60

8.2 Afkortingen 63

9 Bijlagen 64

Bijlage 1: Literatuur/bronnen 65

Page 7: voorbeeld service level agreement (sla) met aandacht voor ...

7

i. Versiebeheer/Wijzigingshistorie

Hier worden de wijzigingen op de SLA beschreven die zijn goedgekeurd en door wie.

Versies

Versie Datum Auteurs Samenvatting van de wijzigingen

0.1 Auteur Initieel document

Goedkeuring

Versie Datum Naam

Page 8: voorbeeld service level agreement (sla) met aandacht voor ...

8

ii. Distributielijst

Hier worden de functies/personen opgesomd die een afschrift dienen te ontvangen van deze SLA.

Ter informatie aan

Versie Datum Naam

0.1

Page 9: voorbeeld service level agreement (sla) met aandacht voor ...

9

iii. Leeswijzer

Hier wordt beschreven hoe dit SLA het beste gelezen kan worden, afhankelijk van de functie/taak

en achtergrondkennis van de lezer.

Page 10: voorbeeld service level agreement (sla) met aandacht voor ...

10

0 Positie SLA en gerelateerde documenten

Hier wordt de samenhang beschreven tussen het contract/overeenkomst en de SLA en de relatie

met documenten die mogelijk als bijlagen op de SLA zijn bijgevoegd.

Voorbeelduitwerking

Voorbeelddocumenten die mogelijk als bijlagen op de SLA zijn bijgevoegd, zijn:

Algemene voorwaarden. Bijvoorbeeld FENIT-voorwaarden 2003, ICT~Office voorwaarden

2009, BIZA-voorwaarden of ARBIT-voorwaarden.

De Algemene voorwaarden van de dienstleverancier.

Het Dossier met Afspraken en Procedures (DAP)

Het DAP is de invulling en nadere detaillering van afspraken tussen gemeente en

dienstleverancier.

Een Dossier Financiële Afspraken (DFA)

Het DFA bevat de financiële afspraken inzake de dienstverlening.

Een Service Quality Plan (SQP)

Het SQP bevat de noodzakelijke informatie die nodig is om de kwaliteit van een ICT-dienst bij

te sturen. In het SQP worden voor elke dienst streefwaarden gedefinieerd, in de vorm van

Perfomance Indicatoren (PI’s), zoals responstijden, beschikbaarheid, doorlooptijden, kosten et

cetera.

Een Service Improvement Plan (SIP)

Het SIP bevat acties, doelen en opleverdata die de verbetering van een ICT-dienst tot doel

hebben.

Een Dienstencatalogus

De Dienstencatalogus bevat een gedetailleerd overzicht van de aangeboden diensten en het

niveau van de dienstverlening. De dienstencatalogus is bedoeld voor de klant en moet de

diensten in voor de klant begrijpelijke bewoordingen beschrijven.

Een bewerkersovereenkomst1

De bewerkersovereenkomst bevat afspraken en maatregelen die de verantwoordelijke

genomen wil hebben door de bewerker.

1 Het opstellen van een bewerkersovereenkomst dient ertoe te waarborgen dat de verplichtingen die vanuit de Wbp op de verantwoordelijke rusten, ook door de bewerker worden nageleefd. Belangrijk is dat volgens de Wbp de verantwoordelijke aanspreekbaar blijft voor de gegevens die onder zijn verantwoordelijkheid door de bewerker worden verwerkt.

Page 11: voorbeeld service level agreement (sla) met aandacht voor ...

11

1 Inleiding

Deze SLA beschrijft de door de dienstleverancier geleverde diensten en specificaties van de

applicatie, systeem of dienst, zoals deze aan de gemeente wordt aangeboden.

De insteek bij het opstellen van een SLA is een partnership gericht op een ‘goede’ samenwerking

tussen gemeente en dienstleverancier. In een SLA wordt de link gelegd tussen de zakelijke

behoeften/verwachtingen van de gemeente en de hiervoor benodigde diensten/technologie. Er

dient dan ook bij de in dit document genoemde onderwerpen steeds gekeken te worden of deze

aansluiten bij de gedefinieerde behoefte-/doelstelling. Voorbeelden hiervan zijn het

beëindigingsproces (in paragraaf 2.1) en ontbinding en garanties (in paragraaf 2.2). De insteek

dient ten allen tijde te zijn dat wordt voorkomen dat zowel de gemeente als de dienstleverancier in

de stand van ‘verschuilen / excuses’ komen te staan. Dit kan bereikt worden door afspraken te

maken over het ‘wat’ er geleverd dient te worden en niet over ‘het’ hoe. De onderhandelingen

tussen de gemeente en de dienstleverancier dienen dan ook te gaan over eenheden die begrijpelijk

en meetbaar zijn voor de gemeente, zoals het aantal transacties per uur of het aantal e-mails per

dag en niet over CPU2 tijd en hoeveelheden gebruikt geheugen. Er dienen ook afspraken gemaakt

te worden over het testen van de gemaakte afspraken of anders geformuleerd aantonen dat de

dienstleverancier kan voldoen aan de doelstelling.

Het opstellen van een SLA is geen eenvoudige zaak. Het resultaat van een SLA is dat de

dienstleverancier kan laten zien dat de gewenste dienst wordt geleverd, op een wijze die

begrijpelijk is voor de gemeente, conform vooraf gedefinieerde meetpunten en gerealiseerde

resultaten. Samengevat weet de dienstleverancier wat er van hem verwacht wordt en wordt door

de dienstleverancier de zakelijke behoefte van de gemeente ingevuld.

Zoals vermeld in het leesadvies bevat dit document een template/globale lijst met

aandachtspunten die relevant zijn voor het opstellen van een Service Level Agreement (SLA) met

concrete voorbeelduitwerkingen. Het toesnijden op iedere gemeentelijke individuele

praktijksituatie is ondoenlijk en er kan dan ook niet ingegaan worden op het afbreukrisico’s die in

uw specifieke situatie gelopen wordt. Op basis van het af te nemen product en/of dienst en eigen

risicoafweging dient de gemeente te beslissen welke aandachtspunten uit deze template relevant

zijn. Deze relevante aandachtspunten kunnen daarna door de gemeente gebruikt worden om de

nieuwe SLA op te stellen of de SLA van de dienstleverancier te beoordelen. Het kan ook

voorkomen dat bepaalde onderwerpen en/of detaillering niet in deze SLA worden beschreven maar

in een ander document worden opgenomen zoals Dossier afspraken en Procedures (DAP,

inkoopvoorwaarden, contract/overeenkomst of bewerkersovereenkomst). Denk hierbij aan

kwantitatieve afspraken zoals aantal gebruikers. Deze aantallen kunnen in de loop van de tijd

veranderen en hiervoor wil je niet telkens de SLA aanpassen.

Het is niet de bedoeling om een compleet overzicht te geven van de doelstellingen op het gebied

van dienstenniveaus (Service Level Objectives (SLOs)), maar om voorbeelden te geven die

kunnen worden gebruikt bij het opstellen van de eisen door de gemeenten.

2 CPU = Central Processing Unit.

Page 12: voorbeeld service level agreement (sla) met aandacht voor ...

12

1.1 Doel van de SLA

Doel van de SLA is het op een heldere en eenduidige wijze beschrijven van wederzijdse,

kwalitatieve en kwantitatieve, verwachtingen tussen de gemeente en dienstleverancier over het te

realiseren dienstenniveau en de rapportage daarover. Op basis hiervan kan de kwaliteit en

uitvoering van de dienstverlening worden gemonitord en indien noodzakelijk worden verbeterd

zodat de ‘goede’ relatie/samenwerking tussen beide partijen optimaal wordt gehouden.

Dienstleverancier voorziet in de beheersdiensten, overeenkomstig de beschreven dienstenniveaus

en overige afspraken.3 De diensten hebben betrekking op instandhouding van de applicatie,

systemen of diensten en de aanpassingen hieraan ten gevolge van wijzigende omstandigheden en

behoeften binnen de gemeente.

De gemeente beoogt door de relatie met de dienstleverancier het volgende te realiseren:

continuïteit van de bedrijfsprocessen

borging van kennis van applicatie, systemen of diensten

et cetera.

1.2 Vastlegging van partijen en goedkeuring

Hier worden de contactgegevens van zowel de vertegenwoordiger van de leverancier van de dienst

(Opdrachtnemer) als van de afnemer (Opdrachtgever) vermeld. Dit zijn meestal de personen die

goedkeuring geven aan de SLA en namens beide partijen de SLA ondertekenen.

Voorbeelduitwerking

In dit document is de Service Level Agreement (SLA) beschreven zoals overeengekomen tussen:

Opdrachtgever <gemeente>, hierbij vertegenwoordigd door de heer/mevrouw <naam>, (hierna:

Opdrachtgever).

en

Opdrachtnemer <leverancier>. gevestigd te <plaatsnaam>, hierbij vertegenwoordigd door de

heer/mevrouw <naam> (hierna: ‘Opdrachtnemer’),

Tezamen genoemd: Partijen.

1.2.1. Vertegenwoordiger leverancier

Hier worden de contactgegevens van de vertegenwoordiger van de leverancier (Opdrachtnemer)

van de dienst vermeld, meestal de service level manager.

3 De beschreven dienstenniveaus kunnen ook vastgelegd zijn in het Dossier afspraken en Procedures (DAP).

Page 13: voorbeeld service level agreement (sla) met aandacht voor ...

13

Voorbeelduitwerking

Organisatienaam: <leverancier> gevestigd te <plaatsnaam>

Naam: heer/mevrouw <naam>

Functie: <functieomschrijving>

1.2.2. Vertegenwoordiger gemeente

Hier worden de contactgegevens van de vertegenwoordiger van de gemeente (Opdrachtgever)

vermeld.

Voorbeelduitwerking

Organisatienaam: <gemeente>

Naam: heer/mevrouw <naam>

Functie: <functieomschrijving>

1.2.3. Goedkeuring

De goedkeuring van de SLA is de gezamenlijke verantwoordelijkheid van de gemeente en de

Opdrachtnemer (service level manager).

1.3 Ingangs- en einddatum

Hier worden de ingangs- en einddatum van de SLA beschreven, tevens wordt aangegeven of er een

(tussen)evaluatie plaats zal vinden.

Voorbeelduitwerking

Het SLA heeft als ingangsdatum <ingangsdatum SLA> en heeft een looptijd van <looptijd> jaar.

Er vindt na een <periode, bijvoorbeeld één jaar> een review plaats wat kan leiden tot aanpassing

van het SLA.

Page 14: voorbeeld service level agreement (sla) met aandacht voor ...

14

2 Governance

Governance is het proces waarbij de dienstverlening wordt bestuurd en gecontroleerd. Het

belangrijkste aandachtspunt is de manier waarop wijzigingen en updates van een dienst worden

beheerd, of het wijzigingsverzoek nu afkomstig is van de gemeente die de dienst afneemt of van

de dienstleverancier.

2.1 Verlenging en beëindiging

Afspraken over het verlengen van de looptijd en beëindigen van de SLA en tevens afspraken over

het voortijdig beëindigen van de SLA (exitprocedure/-strategie). De beschrijving van de

exitprocedure is te vinden in het Dossier afspraken en Procedures (DAP). Optioneel, kan dit ook in

de inkoopvoorwaarden, het contract/de overeenkomst of de bewerkersovereenkomst worden

beschreven.

Voorbeelduitwerking

De afspraak met betrekking tot het verlengen van het SLA kan, bijvoorbeeld stilzwijgend, door

middel van berichtgeving of na onderling overleg zijn.

2.1.1. Beëindigingsproces

Het beëindigingsproces vindt plaats wanneer de gemeente die de dienst afneemt, of de

dienstleverancier, ervoor kiest om de overeenkomst te ontbinden. Het beëindigingsproces dient

een stappenplan te bevatten die de gemeente in staat stelt om de gemeentelijke gegevens binnen

een aangegeven tijdsperiode veilig te stellen, voordat de dienstleverancier de gemeentelijke

gegevens uit systemen van de dienstleverancier wist (inclusief back-ups, hiervoor geldt mogelijk

een ander tijdschema). De dienstleverancier kan mogelijke gegevens die betrekking hebben op de

gemeente en hun gebruik van de dienst, verwijderen of aggregeren. Dit is in het algemeen wel

beperkt tot afgeleide gegevens met betrekking tot de door de gemeente uitgevoerde activiteiten.

Voorbeelduitwerking

De details met betrekking tot het beëindigingsproces dienen duidelijk te worden beschreven door

middel van dienstverleningsniveaus (doelstellingen). Voorbeelden van relevante

dienstverleningsniveaus (doelstellingen) in relatie tot het beëindigen van de SLA zijn:

Terughaalperiode Specificeert de tijdsperiode waarbinnen de gemeente een kopie

van de gemeentelijke gegevens kan veiligstellen (verkrijgen) die

in de externe dienst zijn opgeslagen.

Bewaringstermijn Verwijst naar de tijdsperiode waarbinnen de dienstleverancier

back-ups van de gemeentelijke gegevens bewaart tijdens het

beëindigingsproces. Bijvoorbeeld in het geval van problemen bij

het veiligstellen (verkrijgen) van de gegevens of in verband met

wet- en regelgeving.

Deze periode kan worden beïnvloed door wettelijke eisen,

waardoor de onder- of bovengrens van de termijn waarop de

dienstleverancier kopieën van gemeentelijke gegevens mag

bewaren, aangepast dient te worden.

Page 15: voorbeeld service level agreement (sla) met aandacht voor ...

15

Achtergebleven gegevens Verwijst naar een beschrijving van alle gemeentelijke gegevens

die na de beëindiging nog aanwezig zijn bij de dienstleverancier.

Het gaat hierbij meestal om afgeleide gegevens van de dienst, die

mogelijk onderworpen kunnen worden aan wettelijke controles.

2.2 Ontbinding en garanties

Beschrijving van de ontbindende voorwaarden. Maar ook de garanties met betrekking tot de

overdracht en vernietiging van gegevens.4 Bijvoorbeeld het langdurig niet halen van de

afgesproken dienstenniveaus. Optioneel, kan dit ook in de inkoopvoorwaarden, het contract/de

overeenkomst of de bewerkersovereenkomst worden beschreven.

2.3 Wijzigingsbeheer

Diensten zijn over het algemeen niet statisch en kunnen van tijd tot tijd veranderen. Voorbeelden

van wijzigingen zijn wijzigingen in functionaliteit, wijzigingen aan de interfaces van de dienst en

het toepassen van software-updates (patchmanagement). Wijzigingen op de in de SLA vastgelegde

regelingen, prestaties en rapportages kunnen zowel een incidenteel als een blijvend (structureel)

karakter hebben.

Incidenteel: Bij deze wijzigingen gaat het om een eenmalige, kortstondige afwijking van de

inhoud van het SLA, waarbij het SLA als zodanig niet wijzigt.

Structureel: Een wijziging is structureel wanneer ten gevolge van deze wijziging de inhoud van

het SLA verandert.

Wijzigingen met betrekking tot een bepaalde dienst kunnen van invloed zijn op de SLA of op een

ander contractueel document. Gemeenten hebben behoefte aan een redelijke kennisgevingstermijn

voordat wijzigingen aan een dienst doorgevoerd kunnen worden en daadwerkelijk van kracht

worden, zodat zij hierop adequaat kunnen anticiperen en plannen.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot wijzigingen met

betrekking tot de SLA zijn:

Meldingen van

dienstwijzigingen

Beschrijft het type wijziging (zoals SLA of functionele

wijzigingen), het mechanisme en de periode voor de

dienstleverancier om de gemeente in kennis te stellen van

voorgenomen wijzigingen in de dienst.

Percentage tijdige meldingen

van dienstwijzigingen

Het aantal wijzigingsnotificaties binnen een vooraf vastgestelde

tijdsperiode ten opzichte van het totaal aantal

wijzigingsnotificaties, uitgedrukt als een percentage.

Wijzigingen op de SLA worden in het SLA overleg tussen de beslissingsbevoegde

vertegenwoordigers van de gemeente en dienstleverancier (service level manager) afgestemd.

Wanneer één van de partijen aanleiding ziet om wijzigingen in het SLA aan te brengen, doet deze

partij hiertoe een schriftelijk voorstel aan de andere partij. Vervolgens treden de partijen hierover

4 Zie ook paragraaf 5.1.2 ‘Beschikbaarheidsdoelen’ in dit document.

Page 16: voorbeeld service level agreement (sla) met aandacht voor ...

16

in overleg. Een tussentijdse aanpassing van het SLA verkrijgt rechtskracht na overeenstemming en

ondertekening door de daartoe bevoegde vertegenwoordigers van beide partijen.

Voorbeelduitwerking

Beschrijving van de procedure voor het wijzigen/herzien van de SLA. Vast te leggen items zijn:

Opsomming van zaken die leiden tot een wijziging van de SLA.

De gehanteerde wijzigingsprocedure (wijze, tijdstip, overleg). De bijbehorende procedure is

opgenomen in het DAP.

Vorige wijzigingen en versies van de SLA, inclusief de data waarop de verschillende versies in

gebruik waren (zie ook het onderdeel versiebeheer).

Wijzigingen in de dienst (content en/of ondersteunende software) kunnen alleen na

goedkeuring van beide partijen worden gerealiseerd. Door de dienstleverancier wordt een

release agenda opgesteld en gecommuniceerd met de gemeente. Deze release agenda houd

rekening met de jaarplanning en het gebruikersperspectief vanuit de gemeentelijke

medewerkers. Deze release agenda geeft in ieder geval inzicht in:

o Het maximaal aantal major releases per jaar dat mogelijk is.

o Of maandelijks een onderhoudsrelease mogelijk is.

o Hoe met verwerking van tussentijdse patches in productie wordt omgegaan.

De dienstleverancier realiseert de wijzigingsverzoeken conform de gemaakte afspraken. De

wijzigingsverzoeken worden, indien mogelijk, gebundeld tot een nieuwe release.

De dienstleverancier actualiseert, indien nodig, voor iedere wijziging de relevante documenten

uit, waarna de gemeente deze aanpassing(en) beoordeeld. De wijziging is pas afgerond als de

gemeente de bijbehorende aanpassing(en) heeft geaccepteerd.

De dienstleverancier reageert binnen een vooraf vastgestelde tijdsperiode, bijvoorbeeld tien

werkdagen, op een geaccordeerd verzoek met een impactanalyse en een plan van aanpak.

Page 17: voorbeeld service level agreement (sla) met aandacht voor ...

17

3 Dienstverlening, doelen en resultaten

3.1 Dienstverlening

Aard van de uitbestede activiteiten of de ingekochte of geleverde goederen/diensten.

3.1.1. Belang van de dienst

Hier worden specifieke functionaliteit met betrekking tot de dienst beschreven. Deze specifieke

functionaliteiten kunnen van essentieel belang zijn vanuit het perspectief van de gemeente om

gebruik te maken van deze dienst.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot het belang van

de dienst zijn:

Externe connectiviteit Specificeert de mogelijkheden van de dienst om een verbinding te

maken met systemen en diensten die geen onderdeel uitmaken

van de dienst. De betreffende systemen en diensten kunnen

andere diensten zijn, of systemen en diensten die geen onderdeel

uitmaken van de infrastructuur van de dienstverlener.

Bijvoorbeeld systemen en diensten die binnen de infrastructuur

van de gemeente draaien.

3.1.2. Identificatie van essentiële componenten

Hier wordt onder andere de essentiële hard- en software beschreven, maar ook de gemeentelijke

(vitale) bedrijfsfuncties die door de dienst ondersteund worden. Deze informatie kan verkregen

worden uit een door de gemeente uitgevoerde baselinetoets BIG, diepgaande risicoanalyse of

classificatie van informatie verkregen informatie.

Voorbeelduitwerking

Er zijn maatregelen genomen voor het dusdanig registreren van componenten, zodat voor de

andere beheerprocessen voldoende gegevens beschikbaar zijn over de componenten die tezamen

de dienst realiseren. Voorbeelden van maatregelen tegen onvoldoende configuratiebeheer zijn:

Er is een correcte registratie van alle in gebruik zijnde en nieuw in te kopen hard- en software.

Er bestaat een periodieke controle op de volledigheid van de configuratiedatabase.

3.1.3. Vitale bedrijfsfuncties, processen en activiteiten

Hier worden de vitale gemeentelijke bedrijfsfuncties, processen en activiteiten die door de (ICT-)

dienst ondersteund worden beschreven. Hierbij is input van de gemeente uiteraard onontbeerlijk.

Page 18: voorbeeld service level agreement (sla) met aandacht voor ...

18

De gemeente geeft aan de dienstleverancier aan wat voor hen van belang is. Hier wordt ook

vermeld of er (bijzondere) persoonsgegevens worden verwerkt.

Voorbeelduitwerking

Voorafgaand aan het afsluiten van een contract voor uitbesteding of externe inhuur is bepaald

welke waarde en gevoeligheid de informatie heeft waarmee de dienstleverancier in aanraking kan

komen en of hierbij eventueel aanvullende beveiligingsmaatregelen nodig zijn.

3.1.4. Overige essentiële zaken

Hier wordt onder andere de essentiële hard- en software beschreven, het (laten) testen van de

dienst en de controle op de beveiligingsmaatregelen. In de SLA dient dan ook vastgelegd te

worden welke beveiligingsmaatregelen vereist zijn, dat deze door de dienstleverancier getroffen

zijn en worden nageleefd en dat beveiligingsincidenten onmiddellijk worden gerapporteerd. Ook

dient beschreven te zijn hoe die beveiligingsmaatregelen door de dienstleverancier te controleren

zijn (bijvoorbeeld audits en penetratietests) en hoe het toezicht is geregeld.

3.1.5. Business impact bij verlies van de dienst

Hier wordt de business impact beschreven bij verlies van de dienst op basis van de resultaten van

de uitgevoerde baselinetoets BIG5 of de handreiking classificatie6.

3.2 Gebruiksresultaat

Beschrijving van het gewenste gebruiksresultaat, hier worden de kwalitatieve en kwantitatieve

afspraken voor het te realiseren dienstenniveau beschreven.

Voorbeelduitwerking

Voorbeeld gebruiksresultaat is dat medewerkers gebruik kunnen maken van de dienst zonder

beperkt te worden door locatie of tijd.

3.3 Garanties

Beschrijving van de gewenste resultaten in termen van garanties. Hier worden de kwalitatieve en

kwantitatieve afspraken voor het te realiseren dienstenniveau beschreven.

Voorbeelduitwerking

Voorbeeld van kwalitatieve en kwantitatieve afspraak met betrekking tot het gewenste resultaat is

dat er een hoge beschikbaarheid wordt vereist tijdens kantoortijden.

5 Zie hiervoor ook het operationele product ‘Baselinetoets BIG’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 6 Zie hiervoor ook het operationele product ‘Handreiking dataclassificatie’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG).

Page 19: voorbeeld service level agreement (sla) met aandacht voor ...

19

3.4 Kwaliteit

Hier worden de kwaliteitsnormen, certificeringen et cetera waaraan de dienstleverancier dient te

voldoen beschreven.

3.5 Dienstverleningstijden

Hier worden de afspraken met betrekking tot de beschikbaarheid van de dienst vastgelegd.

Voorbeelduitwerking

Voorbeeld afspraken met betrekking tot de beschikbaarheid van de dienst zijn: 7x24x365, tijdens

kantoortijden et cetera.

3.5.1. Support (service-/helpdesk)

Support is de dienstverlening die door de dienstleverancier wordt geleverd om incidenten,

problemen en vragen van de gemeente af te handelen. Hier worden afspraken met betrekking tot

reactie- en oplostijden vastgelegd. Hierbij dient rekening gehouden te worden met de volgende

uitgangspunten:

Gebaseerd op basis van prioriteiten die zijn vastgelegd in een prioriteitentabel.

Hoe de vaststelling van de prioriteiten dient plaats te vinden.

Hoe de classificatie van incidenten dient plaats te vinden.

Wat de reactie- en oplostijden (responstijden) zijn voor de verschillende prioriteiten en

incidenten.

Et cetera.

De details met betrekking tot support dienen duidelijk te worden beschreven door middel van

dienstverleningsniveaus (doelstellingen).

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot support zijn:

Openingstijden Specificeert de uren die de dienstleverancier aan ondersteuning

biedt aan de gemeente om verzoeken van de gemeente af te

handelen.

De servicedesk van de dienstleverancier is per e-mail bereikbaar:

24 uur per dag 7 dagen per week, 365 dagen per jaar

(24x7x365).

Dit kan ook beperkter worden afgesproken.

De openingstijden van de dienstleverancier kunnen hier als

uitgangspunt dienen. Tevens spelen hierbij de openingstijden

van de servicedesk/contactpersoon bij de gemeente een

belangrijke rol. Deze kunnen in principe alleen de meldingen

Page 20: voorbeeld service level agreement (sla) met aandacht voor ...

20

doen bij de dienstleverancier. Indien gewerkt wordt met een

Single Point Of Contact aan zowel de kant van de gemeente

als aan de kant van de dienstleverancier, dienen deze

openingstijden op elkaar afgestemd te zijn. Hoe de melding

intern binnen de gemeente plaats mag vinden dient door de

gemeente te worden uitgewerkt in lijn met de afspraken in

deze SLA.

Als er andere manieren van melding worden afgesproken

moet deze paragraaf (en wie de melding mag doorgeven)

aangepast worden aan de afgesproken situatie. Hierbij dient

wel het streven te zijn dit zoveel mogelijk te standaardiseren

om te voorkomen dat voor elke type ondersteuning er andere

afspraken gelden. Dit geeft veel verwarring en misverstanden.

De servicedesk is telefonisch bereikbaar: 5 werkdagen per week

van 07:00 uur tot en met 21:00 uur, exclusief officieel erkende

Nederlandse feestdagen.

Voor prioriteit 1 (P1) incidenten is een stand-by regeling

aanwezig.

Opmerking: De gemeente dient ook te kunnen beschikken

over een stand-by regeling voor prioriteit 1 incidenten.

Opmerking: De gemeente dient in feite dezelfde beschikbaarheid

voor haar eigen servicedesk te regelen.

Reactiesnelheid Specificeert de maximale tijd waarbinnen de dienstleverancier een

eerste reactie dient terug te koppelen op meldingen en vragen

van de gemeente.

De reactiesnelheid kan variëren, afhankelijk van de

classificatie/prioriteit van het verzoek ingediend door de

gemeente. Een kortere reactietijd wordt geassocieerd met een

hogere prioriteit.

Oplostijd Verwijst naar de oplostijd van verzoeken ingediend door de

gemeente. De tijd waarbinnen de dienstleverancier de

noodzakelijke activiteiten dient te voltooien om het verzoek van

de gemeente af te handelen.

De oplostijd kan variëren, afhankelijk van de classificatie/prioriteit

van het verzoek ingediend door de gemeente. Een kortere

oplostijd wordt geassocieerd met een hogere prioriteit.

3.5.2. Beschikbaarheid van de dienst (uptime)

Beschikbaarheid is de eigenschap dat de dienst toegankelijk en bruikbaar is op het moment dat de

gemeente gebruik wil maken van de dienst. Beschikbaarheid is een belangrijke

dienstniveaudoelstelling, want het beschrijft of de dienst daadwerkelijk gebruikt kan worden. Het

wordt meestal uitgedrukt in numerieke waarden om zinvolle uitspraken te doen die nuttig zijn voor

de gemeente. Het is belangrijk om de beschikbaarheid van de dienst vast te stellen in combinatie

met het belang van beschikbaarheid van de specifieke toepassing voor uw gemeente.

Page 21: voorbeeld service level agreement (sla) met aandacht voor ...

21

De vraag wat ‘bruikbaar’ betekent is een ingewikkeld vraagstuk, het antwoord hangt onder andere

af van de dienst die afgenomen wordt. Een dienst kan beschikbaar zijn, maar de performance kan

zo slecht zijn dat de dienst in feit onbruikbaar is. Op dezelfde manier kan de dienst beschikbaar

zijn, maar geeft foutmeldingen op geldige verzoeken. Het is aan te raden om over deze aspecten

van de beschikbaarheid van de dienst duidelijke afspraken te maken in de SLA. Houdt hierbij ook

rekening met of en hoe regulier onderhoud wordt gepland en aangekondigd. Maak hierbij

afspraken welke componenten (technisch of functioneel) binnen de dienstverlening vallen waar de

SLA en dus de beschikbaarheidsgaranties op van toepassing zijn.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot de

beschikbaarheid van de dienst zijn:

Uptime / beschikbaarheid Beschrijft de tijd over een vooraf gedefinieerde periode waarin de

dienst beschikbaar was, ten opzichte van de totale tijd in deze

periode, uitgedrukt in een percentage.

Sommige diensten geven vooraf aan dat de betreffende dienst

niet beschikbaar is tijdens bepaalde perioden in verband met

onderhoud (onderhoudswindow7). Het is gebruikelijk om bij het

berekenen van het niveau van up-time deze onderhoudsperiodes

niet mee te nemen.

In dit geval:

Up-time = totale beschikbare tijd - (totale downtime – downtime

vanwege onderhoud).

Beschikbaarheid (servicewindow8)

De dienst is 24 uur per dag, 7 dagen per week en 365 dagen per

jaar (24x7x365) beschikbaar voor gebruik door de gemeente, met

een minimale uptime van 95% per jaar; de 5%

onbeschikbaarheid wordt veroorzaakt door

onderhoudswerkzaamheden of het optreden van storingen.

of

De dienst is 24 uur per dag, 7 dagen per week en 365 dagen per

jaar (24x7x365) beschikbaar, met een minimale beschikbaarheid

van 99,4% per maand (beschikbaarheidniveau9). Binnen de

reguliere werktijden van de gemeente (werkdagen tussen 07.00

uur tot 21.00 uur) moet het beschikbaarheidpercentage 99,9%

zijn. Gepland onderhoud wordt niet meegenomen in de

berekening van het beschikbaarheidpercentage.

Percentage succesvolle

aanvragen

Beschrijft het aantal verwerkte verzoeken door de dienst zonder

een foutmelding ten opzichte van het totaal aantal ingediende

aanvragen, uitgedrukt in een percentage.

Percentage van tijdig

afgehandelde

Beschrijft het aantal dienstverleningsverzoeken binnen een vooraf

gedefinieerde periode ten opzichte van het totaal aantal

7 Een (afgesproken) tijdvak waarin onderhoud plaatsvindt die mogelijk verstoring veroorzaakt in het gebruik van de dienst. 8 Dit wordt gedefinieerd als het tijdraam/-vak waarbinnen de gedefinieerde dienstverlening met een zekere garantie en met een afgesproken beschikbaarheidsniveau wordt aangeboden. 9 Per te leveren dienst wordt een beschikbaarheidspercentage afgesproken. Bijvoorbeeld 99,5% of 99,9%, afhankelijk van de producten die de gemeente kiest.

Page 22: voorbeeld service level agreement (sla) met aandacht voor ...

22

dienstverleningsverzoeken dienstverleningsverzoeken, uitgedrukt in een percentage.

Het afhandelen van dienstverleningsverzoeken kan sterk variëren,

afhankelijk van de aard van de dienst die wordt afgenomen - van

opslag tot en met gebruikeraccounts. Het is dan ook noodzakelijk

om deze dienstniveaudoelstelling toe te snijden op de specifieke

dienst.

3.5.3. Onderhoud

Hier worden de afspraken met betrekking tot de onderhoud vastgelegd. De uitvoering van

onderhoudswerkzaamheden kan tot gevolg hebben dat de dienst niet beschikbaar is voor gebruik

door de gemeente.

Voorbeelduitwerking

Voorbeeld afspraken die in de SLA beschreven kunnen zijn met betrekking tot onderhoud zijn:

Voor het onderhoud aan de dienst is van te voren een onderhoudsschema vastgesteld en

gecommuniceerd. Uiterlijk vijf werkdagen voor start van de werkzaamheden wordt de

contactpersoon van de gemeente hiervan per e-mail in kennis gesteld.

Op initiatief van de door de dienstleverancier uitgevoerde algemene

onderhoudswerkzaamheden, waardoor de dienst voor geen enkele klant beschikbaar is,

bijvoorbeeld onderhoud van de server. Deze algemene onderhoudswerkzaamheden vinden

maximaal zes keer per jaar plaats, waarbij de dienst maximaal één werkdag niet beschikbaar

is voor gebruik door de gemeente. Het onderhoud wordt minimaal twee werkdagen van

tevoren via e-mail aan contactpersoon van de gemeente en op de website van de

dienstleverancier aangekondigd.

De dienstleverancier kan in onderling overleg met de contactpersoon van de gemeente

besluiten om in voorkomende gevallen tijdens de servicewindow en buiten het geplande

onderhoudsschema onderhoud uit te voeren. De contactpersoon van de gemeente wordt

hiervan tijdig op de hoogte gebracht.

Op initiatief van dienstleverancier en specifiek voor gemeente uitgevoerd onderhoud, zoals het

uitvoeren van een release update. Dit onderhoud vindt maximaal drie keer per jaar plaats op

een in overleg met gemeente te bepalen tijdstip, waarbij de dienst maximaal één werkdag niet

beschikbaar is voor gebruik door gemeente.

Op verzoek van de door de gemeente uitgevoerde onderhoudswerkzaamheden, zoals het

aanbrengen van wijzigingen in de door de gemeente gebruikte software. Het tijdstip hiervan

wordt in overleg tussen dienstleverancier en gemeente bepaald, voor een tijdsduur die

afhankelijk is van de omvang van het onderhoud.

De dienstleverancier zal er altijd naar streven om de werkzaamheden in het weekend of

tussen ´s avonds 18.00 uur en ´s morgens 06.00 uur te laten plaatsvinden.

Bij voorkeur wordt onderhoud uitgevoerd in de nachten van vrijdag op zaterdag en/of van

zaterdag op zondag.

3.5.4. Uitzonderingen op beschikbaarheid dienstverlening

Hier worden de afspraken met betrekking tot de uitzonderingen op de beschikbaarheid van de

dienstverlening vastgelegd.

Page 23: voorbeeld service level agreement (sla) met aandacht voor ...

23

Voorbeelduitwerking

Voorbeeld uitzonderingen met betrekking tot de beschikbaarheid van de dienstverlening zijn:

weekenden, feestdagen, onderhoudsvensters et cetera.

3.5.5. Stand-by

Hier worden de afspraken met betrekking tot de stand-by dienstverlening vastgelegd.

Voorbeelduitwerking

Voorbeeld afspraken met betrekking tot de stand-by dienstverlening zijn: buiten kantoortijden,

tijdens weekenden, feestdagen et cetera.

3.6 On-site ondersteuning

Hier worden de afspraken met betrekking tot het on-site vereiste niveau van ondersteuning

(support) vastgelegd. Denk ook aan toegang door de dienstleverancier op afstand.

Voorbeelduitwerking

Voorbeeldafspraken met betrekking tot het on-site vereiste niveau van ondersteuning (support)

zijn: het ondersteunen van eindgebruikers of ICT-medewerkers et cetera.

3.6.1. Locaties/Ruimtes

Hier worden de afspraken vastgelegd vanaf welke locaties / ruimtes met de dienst gewerkt kan

worden en welke bijzonderheden hierop van toepassing zijn. Bij een SaaS-dienst gelden hiervoor

hoogstwaarschijnlijk geen beperkingen aangezien deze dienst via het internet benaderd kan

worden.

3.6.2. Soorten gebruikers

Hier worden de afspraken vastgelegd welke soorten en aantallen gebruikers van de dienst gebruik

gaan maken. Maak mogelijk gebruik van een bandbreedte (minimaal en maximaal aantal

gebruikers).

Voorbeelduitwerking

Voorbeeld soorten en aantallen gebruikers van de dienst zijn:

100 eindgebruikers vanaf locatie één

50 eindgebruikers vanaf locatie twee

Twee functioneel beheerders

Twee technisch beheerders

Et cetera.

Page 24: voorbeeld service level agreement (sla) met aandacht voor ...

24

3.6.3. Soorten infrastructuren

Hier worden de afspraken vastgelegd met betrekking tot welke soorten infrastructuur worden

ondersteund.

Voorbeelduitwerking

Voorbeeld afspraken over de soorten infrastructuur die worden ondersteund zijn: Vast, mobiel,

speciale netwerken, beveiliging (Virtual Private Network (VPN)).

3.7 Ondersteuning op afstand

Hier worden de afspraken met betrekking tot het vereiste niveau van ondersteuning (support) op

afstand vastgelegd. Denk hierbij aan toegang op afstand tot systemen door de technisch

beheerders van de dienstleverancier/-verlener (beheerders) maar ook aan de gemeentelijke

functioneel beheerders en (eind)gebruikers. Tevens dienen afspraken vastgelegd te worden met

betrekking tot de beveiliging.

Voorbeelduitwerking

Voorbeeld afspraken met betrekking tot het vereiste niveau van ondersteuning (support) op

afstand zijn: Binnenkomende incidenten worden door de help-/servicedesk geregistreerd en in

eerste instantie zo veel mogelijk op afstand opgelost. Als dit niet tot een oplossing leidt, wordt een

beheerder naar de betreffende locatie gestuurd om de gebruiker hulp te bieden.

3.7.1. Locaties/Ruimtes

Hier worden de afspraken vastgelegd vanaf welke locaties/ruimtes ondersteuning op afstand kan

worden geboden. Bij een SaaS-dienst gelden hiervoor hoogstwaarschijnlijk geen beperkingen

aangezien het beheer van deze dienst via het internet uitgevoerd kan worden middels een

beheerinterface.

3.7.2. Soorten gebruikers

Hier worden de afspraken vastgelegd met betrekking tot welke soorten en aantallen gebruikers van

de dienst op afstand gebruik gaan maken. Groepen/gebruikers die toegang tot de dienst worden

toegekend. Maak mogelijk gebruik van een bandbreedte (minimaal en maximaal aantal

gebruikers).

Voorbeelduitwerking

Voorbeeld soorten en aantallen gebruikers die op afstand van de dienst gebruik gaan maken zijn:

100 eindgebruikers vanaf locatie één

50 eindgebruikers vanaf locatie twee

Twee functioneel beheerders

Twee technisch beheerders

Et cetera.

Page 25: voorbeeld service level agreement (sla) met aandacht voor ...

25

3.7.3. Soorten infrastructuur

Hier worden de afspraken vastgelegd met betrekking tot welke soorten infrastructuur worden

ondersteund.

Voorbeelduitwerking

Voorbeeld afspraken over de soorten infrastructuur die op afstand worden ondersteund zijn: Vast,

mobiel, speciale netwerken, beveiliging (VPN).

3.8 Eigendom

Hier wordt beschreven wie de eigenaar is van de gegevens, software en hardware. Hier kunnen

ook afspraken met betrekking tot het intellectuele eigendomsrechten worden beschreven.

Optioneel, kan dit ook in de inkoopvoorwaarden, het contract/overeenkomst of de

bewerkersovereenkomst worden beschreven.

Page 26: voorbeeld service level agreement (sla) met aandacht voor ...

26

4 Communicatie tussen gemeente en

dienstverlener

Voor het bewaken van de afgesproken kwaliteit, het realiseren van de afgesproken

dienstenniveaus en het doorvoeren van veranderingen en verbeteringen (bijvoorbeeld vastgelegd

in verbeterplannen) is regelmatig overleg op diverse organisatieniveaus noodzakelijk. Vastleggen

wanneer gestructureerd overleg plaatsvindt, wie er aan dit overleg deelnemen en wie bij beide

partijen verantwoordelijk is voor de onderlinge relatie. Tevens wordt er een overzicht opgenomen

van alle contactpersonen en verantwoordelijken bij escalatie of calamiteiten. Een nadere

concretisering van deze overlegvormen is opgenomen in het DAP. Denk hierbij aan tijdstippen of

aanleidingen voor overleg en de betrokken personen bij overleg.

Voorbeelduitwerking

Voorbeeldafspraken met betrekking tot de overlegstructuur tussen de gemeente en de

dienstleverancier zijn:

Directie-overleg:

o Frequentie: Bijvoorbeeld eenmaal per (half)jaar.

o Aanwezigen: opdrachtgever van de gemeente, opdrachtnemer van de dienstleverancier,

Service Management gemeente en Service Management leverancier.

o Onderwerpen: monitoring contract en samenwerking, ontwikkelingen.

Dienstenniveau-overleg:

o Frequentie: Bijvoorbeeld eenmaal per maand.

o Aanwezigen: Service Management gemeente en Service Management leverancier.

o Onderwerpen: monitoring SLA, ontwikkelingen en verbeteringen.

4.1 Verantwoordelijke contactpersoon gemeente

Hier worden de contactgegevens van de verantwoordelijke contactpersoon van de gemeente

weergegeven. Dit kan dezelfde persoon zijn als die bij paragraaf 1.2 maar dit kan ook een

operationeel / procesmanager zijn.

Voorbeelduitwerking

Voorbeeld contactgegevens die vastgelegd kunnen worden zijn:

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 gemeente en locaties (meestal een

verwijzing naar de betreffende bijlage).

Standaardformulieren voor onderlinge correspondentie (meestal een verwijzing naar de

betreffende bijlage).

4.2 Verantwoordelijk (klant) manager leverancier

Hier worden de contactgegevens van de service level manager (zie paragraaf 1.1) of de (klant)

manager verantwoordelijk voor het leveren van de dienst van de leverancier weergegeven.

Page 27: voorbeeld service level agreement (sla) met aandacht voor ...

27

4.3 Dienstrapportages

Hier wordt de inhoud en frequentie (interval) van de rapportage beschreven die door de

dienstleverancier wordt opgeleverd. Als gemeente dient u zicht te hebben, te krijgen en te houden

op alles wat te maken heeft met de afgenomen dienstverlening.

Daarnaast kan ook afgesproken worden dat de dienstleverancier periodiek een onderzoek naar de

kwaliteit van de beveiliging laat doen door een onafhankelijke derde. Dergelijk afspraken worden in

de klantleveranciersovereenkomst vastgelegd, waarbij bepaald wordt dat jaarlijks een externe

EDP-auditor de opdracht krijgt een zogenaamde Third Party-Mededeling (TPM) op te stellen. De

TPM bevat een oordeel over de kwaliteit van het stelsel van maatregelen van interne controle en

beveiliging bij de dienstleverancier en biedt de gemeente de garantie dat de dienstleverancier zijn

contractuele beveiligingsafspraken is nagekomen.

Voorbeelduitwerking

Met betrekking tot de rapportage moeten afspraken gemaakt worden betreffende:

Inhoud van de rapportage

Verschijningsfrequentie

Distributie (functionarissen, afdelingen, et cetera)

Een goede rapportage bestaat uit een rapportage over:

Afwijkingen van de afgesproken norm, bijvoorbeeld het uitvallen van een dienst langer dan de

afgesproken normtijd.

Onderwerpen die voor de gemeente relevant zijn en begrepen kunnen worden zoals

beschikbaarheid van de dienst voor de gemeente. De dienstleverancier dient de vertaling te

maken van de beschikbaarheid van alle relevante componenten die de dienst vormen naar een

totale beschikbaarheid voor de gemeente. Voorbeeld: een client-servertoepassing is

beschikbaar als én de client-applicatie én het netwerk én de server beschikbaar zijn.

Het juist, volledig en tijdig (ofwel betrouwbaar) afhandelen van productieopdrachten, zoals het

maandelijks draaien van de opdracht tot uitbetaling van salarissen.

Eventuele incidenten, zoals het ongeautoriseerd verwijderen van bestanden.

Verwachte gebeurtenissen die voor de gemeente belangrijk zijn, zoals gepland onderhoud,

een grote interne verhuizing bij de dienstleverancier waardoor de continuïteit van de

dienstverlening in gevaar zou kunnen komen, et cetera.

De mogelijkheid om ad hoc een rapportage op te vragen, bijvoorbeeld een overzicht van de

beveiligingsincidenten van het afgelopen kwartaal. Hierover worden vooraf wel afspraken

gemaakt, maar er wordt geen periodieke rapportage verstrekt. Op deze wijze kan de

gemeente de aangeboden rapportage naar behoefte zelf regelen.

4.4 Uitzonderingen en klachten

Hier worden de procedures voor de behandeling van uitzonderingen en klachten beschreven.

Bijvoorbeeld gegevens die moeten worden opgenomen in formele klachten, afgesproken

responstijden, escalatieprocedure et cetera. De procedure voor de behandeling van uitzonderingen

en klachten is te vinden in het DAP. Optioneel, kan dit ook in de inkoopvoorwaarden, het

contract/overeenkomst of de bewerkersovereenkomst worden beschreven.

Page 28: voorbeeld service level agreement (sla) met aandacht voor ...

28

4.4.1. Communicatie in geval van escalaties

Aangaande dienstverlening welke buiten de afgesproken dienstenniveaus valt, kan geëscaleerd

worden. Bijvoorbeeld: Eindgebruikers dienen altijd eerst de help-/servicedesk (escalatie niveau

één) te bellen. Overige partijen binnen de gemeente kunnen vanuit hun functie contact opnemen

met hun counterpart bij de dienstleverancier. De escalatieprocedure is te vinden in het DAP en

geeft onder andere aan welke personen betrokken zijn bij escalaties en welke afwijkende clausules

gelden ten opzichte van het SLA (bijvoorbeeld met betrekking tot het verlenen van extra

ondersteuning door de dienstleverancier).

4.4.2. Communicatie in geval van 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. De geschillenprocedure is te vinden in het DAP en geeft onder andere aan welke personen

betrokken zijn bij geschillen, (bijvoorbeeld onafhankelijke derde instantie of persoon), en het feit of

een uitspraak van een onafhankelijke geschillencommissie bindend is of niet.

4.5 Tevredenheidonderzoeken

Hier wordt de procedure beschreven voor het meten van de tevredenheid van de gemeente, deze

meting dient op regelmatige basis plaats te vinden. De procedure voor het meten van de

tevredenheid is te vinden in het DAP.

4.6 Servicebeoordelingen

Hier wordt de procedure beschreven voor de herziening van de dienst met de gemeente, deze

meting dient op regelmatige basis plaats te vinden. De procedure voor het voor de herziening van

de dienst is te vinden in het DAP.

4.7 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 of het functioneren van de dienst(verlening).

Denk hierbij ook aan geheimhoudingsplicht met betrekking tot informatie en in het bijzonder

geheime of vertrouwelijke informatie. Ook kunnen bepalingen worden opgenomen voor

bescherming tegen het overnemen van personeel (concurrentiebeding) of het rechtstreeks

onderhandelen van de gemeente (buiten de dienstleverancier om) met derden over de levering van

(delen van) diensten. Optioneel, kan dit ook in de inkoopvoorwaarden, het contract/overeenkomst

of de bewerkersovereenkomst worden beschreven.

Page 29: voorbeeld service level agreement (sla) met aandacht voor ...

29

5 Dienstenniveau eisen / doelen

In dit hoofdstuk worden de kwalitatieve en kwantitatieve dienstenniveaus vastgelegd voor de

beschikbaarheids-, betrouwbaarheidsdoelen. Op basis van deze dienstenniveaus vindt monitoring

plaats van het geleverde dienstenniveau in relatie met het afgesproken niveau.

Relatie met de tactische Baseline:

Controle en beoordeling van dienstverlening door een derde partij (10.2.2)

Beheer van wijzigingen in dienstverlening door een derde partij (10.2.3)

Capaciteitsbeheer (10.3.1)

5.1 Beschikbaarheidsdoelstellingen

Relatie met de tactische Baseline (zie ook contractmanagement10):

Capaciteitsbeheer (10.3.1)

5.1.1. Niet beschikbaarheidsvoorwaarden

Hier worden de voorwaarden beschreven wanneer de dienst als niet beschikbaar wordt beschouwd.

Houdt hierbij rekening met het de omstandigheid dat de dienst op meerdere locaties wordt

aangeboden en het niet beschikbaar zijn van de dienst als gevolg van beveiligingsincidenten

(bijvoorbeeld dDoS).

5.1.2. Beschikbaarheidsdoelen

De mate waarin aan de vraag naar een product wordt voldaan (servicegraad). Exacte definitie van

hoe de overeengekomen beschikbaarheidsniveaus zal worden berekend op basis van afgesproken

servicetijd en downtime. Meestal uitgedrukt in een percentage. Dit percentage kan gemeten

worden op verschillende plaatsen in de keten.

Voorbeelduitwerking

Voorbeeld van een beschikbaarheidsniveau met een 95% servicegraad betekent dat het

dienst/product 95% van de tijd beschikbaar is.

Relatie met de tactische Baseline:

Back-up (10.5)

Scheiding van faciliteiten voor ontwikkeling, testen en productie (10.1.4)

Opslagbeheer

Aan de opslag en verwerking van de gebruikersgegevens kunnen door de gemeente aanvullende

eisen gesteld worden, bijvoorbeeld ten aanzien van de wijze van bewaren, de bewaartermijn en de

wijze van vernietiging. Eventueel kunnen voor bijzonder vertrouwelijke of privacygevoelige

gegevens aanvullende afspraken worden gemaakt.

10 Zie hiervoor ook het operationele product ‘Contractmanagement’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG).

Page 30: voorbeeld service level agreement (sla) met aandacht voor ...

30

Voorbeelduitwerking

Voorbeeldeisen in de SLA betreffen:

Classificatie van gegevens

Bewaartermijnen

Migratieprocedures

Exit-procedure

Vernietigingsprocedure

De migratie-, exit en vernietigingsprocedures zijn te vinden in het DAP

Uitval van infrastructurele voorzieningen

De wijze waarop de facilitaire en ICT-voorzieningen zijn ingericht is de verantwoordelijkheid van de

dienstleverancier. Voor de gemeente is alleen van belang dat er zodanige infrastructurele

maatregelen zijn getroffen zodat de voortgang en kwaliteit van de dienstverlening niet wordt

aangetast.

Voorbeelduitwerking

Voorbeeldeisen in de SLA betreffen:

Algemene beschikbaarheidseisen

Algemene eisen ten aanzien van de kwaliteit van de infrastructurele voorzieningen

Periodieke audit van het functioneren van de infrastructurele voorzieningen

Onvoldoende scheiding tussen ontwikkel-, test- en productieomgeving

Het aanbrengen van scheiding tussen ontwikkel-, test- en productieomgeving is primair bedoeld

om in ieder geval de productieomgeving zo veel mogelijk te isoleren van verstorende externe

invloeden. Door middel van wijzigingsbeheer en autorisatiebeheer kan deze scheiding verder in

stand worden gehouden. Deze werkzaamheden gebeuren volledig bij de dienstleverancier.

Voorbeelduitwerking

Voorbeeldeisen in de SLA betreffen:

Algemene kwaliteit infrastructuur

Periodieke audit van de kwaliteit van de infrastructuur

Aantasting van systemen en operationele processen

De beveiliging tegen de aantasting van systemen en operationele processen is erop gericht om de

voortgang van de verwerkingsprocessen bij de dienstleverancier te waarborgen. De deskundigheid

en kwaliteit van de operationele werkzaamheden zijn van directe invloed op de reputatie van de

dienstleverancier. Daarnaast kan door een onafhankelijk deskundige periodiek een oordeel

gegeven worden over de algemene kwaliteit van de operationele processen. Hoewel hier sprake is

van processen bij de dienstleverancier dienen er in de SLA wel degelijk uitdrukkelijke eisen gesteld

te worden aan de minimale beschikbaarheid, de verwerkingssnelheid, de capaciteit en de

controleerbaarheid daarvan. Ook is het van groot belang in de SLA aandacht te besteden aan de

procedure die gevolgd wordt bij het uitvallen van de productie. De gemeente moet eisen stellen

aan de snelheid waarmee de productieomgeving wordt hersteld of tot uitwijk wordt overgegaan. De

mate waarin recovery mogelijk is, is deels afhankelijk van de door de gemeente gekozen back-

upmethode.

Page 31: voorbeeld service level agreement (sla) met aandacht voor ...

31

Voorbeelduitwerking

Voorbeeldeisen in de SLA betreffen:

Reputatie dienstleverancier

Beschikbaarheid

Verwerkingssnelheid

Verwerkingscapaciteit

Methode van back-up

Methode van recovery

Uitwijk

Rapportage beveiligingseisen

Periodieke audits

5.1.3. Betrouwbaarheidsdoelen

Hier worden de betrouwbaarheidsdoelen van de dienst beschreven die door de gemeente worden

vereist, meestal gedefinieerd als MTBF (Mean Time Between Failures) of MTBSI (Mean Time

Between Service Incidenten).

Voorbeelduitwerking

Parameters (maatstaf/metric) die gebruikt worden voor het meten en rapporteren van

betrouwbaarheid zijn:

Mean Time Between Failures (MTBF) is de gemiddelde tijd dat een ICT-systeem of -dienst de

overeengekomen dienstverlening (functionaliteit) kan leveren zonder onderbreking. Dit wordt

gemeten vanaf het moment dat het ICT-systeem of -dienst de overeengekomen

dienstverlening (functionaliteit) levert, tot de volgende onderbreking.

Mean Time to Restore Service (MTRS) is de gemiddelde tijd om een ICT-systeem of -dienst te

herstellen na een storing. MTRS wordt gemeten vanaf het moment dat de ICT-systeem of -

dienst niet beschikbaar is totdat deze weer volledig is hersteld en de overeengekomen

dienstverlening (functionaliteit) weer levert.

Mean Time Between Service Incidents (MTBSI) is de gemiddelde tijd vanaf dat een ICT-

systeem of -dienst niet beschikbaar is (vanwege een storing), tot de volgende niet

beschikbaarheid (vanwege een storing). MTBSI = MTBF + MTRS.

5.1.4. Onderhoudbaarheidsdoelen

Hier worden de onderhoudbaarheidsdoelen met betrekking tot de dienst beschreven.

Voorbeelduitwerking

Parameter (maatstaf/metric) die gebruikt wordt voor het meten en rapporteren van

onderhoudbaarheid is:

Mean Time to Restore Service (MTRS), zie voor de definitie paragraaf 5.1.3.

Page 32: voorbeeld service level agreement (sla) met aandacht voor ...

32

5.1.5. Niet beschikbaar in verband met onderhoud

Hier worden afspraken beschreven die te maken hebben met onderhoud van het ICT-systeem of-

dienst. Denk hierbij aan het aantal toegestane periodes van het niet beschikbaar zijn (downtime)

en welke periode vereist is om het niet beschikbaar zijn door te geven aan de gemeente.

Voorbeelduitwerking

De volgende soorten onderhoud worden mogelijk onderscheiden:

Adaptief: Adaptief onderhoud is het aanpassen van de dienst/product en de bijbehorende

documentatie vanwege externe ontwikkelingen (wijzigingen in de omgeving). Bijvoorbeeld

wetswijzigingen. Adaptief onderhoud kan over het algemeen niet worden uitgesteld.

Correctief: Correctief onderhoud is het herstellen van geconstateerde (ad-hoc) fouten in een

van de onderdelen van een dienst/product. Bijvoorbeeld een foutieve berekening in het

systeem. Hier wordt zo snel mogelijk van te voren of zo snel mogelijk achteraf melding van

gedaan. Er wordt pas correctief onderhoud gepleegd als een fout wordt geconstateerd. Als de

fout eenmaal is geconstateerd, kan het onderhoud niet meer worden uitgesteld.

Functioneel onderhoud: Het uitbreiden of wijzigen van de functionaliteit van de

programmatuur.

Perfectief: Perfectief onderhoud is het verbeteren van de prestaties van de dienst/product.

Bijvoorbeeld het anders indexeren van tabellen waardoor de query’s sneller werken. Perfectief

onderhoud kan worden uitgesteld, omdat het geen betrekking heeft op fouten, maar op

verbeteringen.

Preventief onderhoud: Preventief onderhoud ter voorkoming van fouten in een van de functies

van de dienst of componenten van het product. Bijvoorbeeld het vergroten van de

schrijfruimte of geheugencapaciteit. Deze vorm van beheer is vooral proactief. Het voorkomen

van fouten staat hier centraal.

o Preventief gepland onderhoud: De dienstleverancier werkt met vaste periodieke

onderhoudsvensters voor regulier (Bijvoorbeeld om eventueel optredende fouten voor of

voor het aanbrengen van wijzigen en/of installeren van nieuwe versies) onderhoud aan de

ICT-infrastructuur. In de SLA van de afgenomen dienst wordt dit onderhoudsvenster

vastgelegd.

o Preventief ongepland onderhoud: Daarnaast onderscheidt de dienstleverancier ongepland

onderhoud. Deze vorm van onderhoud wordt een aantal nader te bepalen werkdagen van

tevoren aangekondigd. Dit aantal dagen wordt vastgelegd in de SLA.

5.1.6. Onderhoudsbeperkingen

Hier worden afspraken beschreven met betrekking tot onderhoudsbeperkingen. Bijvoorbeeld

toegestane onderhoudsvensters, wanneer mag er geen onderhoud plaatsvinden en procedures om

de geplande onderbrekingen in de dienstverlening aan te kondigen. De procedures om de geplande

onderbrekingen in de dienstverlening aan te kondigen zijn te vinden in het DAP.

Page 33: voorbeeld service level agreement (sla) met aandacht voor ...

33

5.1.7. Beschikbaarheidsrapportage

Hier worden de eisen ten aanzien van de beschikbaarheidsrapportage beschreven. Verwijs naar

een bijlage waar een voorbeeld van de rapportage is opgenomen.

5.1.8. Definities

Hier worden definities gegeven van bijvoorbeeld grote incidenten en spoedwijzigingen.

5.2 Capaciteit / prestatiedoelstellingen en garanties

Relatie met de tactische Baseline:

Capaciteitsbeheer (10.3.1)

Controle van systeemgebruik (10.10.2)

Capaciteitsbeheer is zodanig geregeld dat de gevraagde dienstenniveaus gehaald en onderhouden

kunnen worden tegen aanvaardbare kosten. Houdt hierbij rekening met het feit dat:

Op mogelijke groei van de capaciteitsvraag wordt geanticipeerd.

De specifieke capaciteitsbehoefte per systeem is vastgelegd.

5.2.1. Benodigde capaciteit

Hier worden de benodigde capaciteitseisen, op basis van de onder- en bovengrens, beschreven

voor de betreffende dienst. Denk hierbij aan de eisen met betrekking tot transacties en gebruikers.

Voorbeelduitwerking

Voorbeelden van benodigde capaciteitseisen zijn:

Transacties Hier wordt het aantal en soort transactie beschreven. Bijvoorbeeld

tien berichten per seconde, 100 webpage bevragingen per

minuut.

Gebruikers Hier wordt het aantal en soort gebruiker beschreven. Bijvoorbeeld

twee functioneel beheerders, 100 concurrent eindgebruikers. (zie

ook paragraaf 3.7.2 en 3.8.2)

Dienstverleningstijden Hier worden afspraken beschreven met betrekking tot periodiciteit

(bijvoorbeeld dagelijks of wekelijks) en seizoensgebonden

afwijkingen. Bijvoorbeeld iedere werkdag tussen 08:00 uur en

18:00 uur, weekenden en schoolvakanties minder gebruikers. (zie

ook paragraaf 3.6)

Capaciteit geeft de maximale hoeveelheid weer van een bepaalde eigenschap

(kenmerk/karakteristiek) van de dienst. Het is vaak een belangrijke waarde voor gemeenten om te

weten wanneer ze gebruik gaan maken van een dienst. Relevante eigenschappen kunnen variëren,

afhankelijk van de mogelijkheden die door de dienst worden ondersteund (geboden). Het is ook

vaak dat meerdere eigenschappen relevant zijn voor een bepaalde dienst met de bijbehorende

capaciteit per eigenschap. Afspraken met betrekking tot de capaciteit dienen duidelijk in de SLA te

Page 34: voorbeeld service level agreement (sla) met aandacht voor ...

34

worden beschreven voor een dienst. Merk op dat de capaciteit dienstniveaudoelstellingen verwijzen

naar de capaciteiten zoals deze worden gezien door een individuele gemeente en dat reflecteert

niet het totaal aan capaciteiten die door de dienstleverancier wordt ondersteund. Vaak kan de

gemeente capaciteitsgrenzen voor hun dienst(en) aanpassen door het aanvragen van een wijziging

in hun abonnement.

Er zijn een aantal dienstniveaudoelstellingen, die betrekking hebben op de capaciteit van een

dienst. Het gaat hierbij onder andere om de hoeveelheid opgeslagen data, aantal gebruikers,

aantal profielen, aantal transacties, aantal servicedesk calls, aantal (gelijktijdige) hits op de

website, verwachte groei van deze dienstniveaudoelstellingen et cetera.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot de benodigde

capaciteit van de dienst zijn:

Aantal gelijktijdige

verbindingen

Verwijst naar het maximale aantal afzonderlijke connecties van

een gemeente die gelijktijdig een verbinding met de dienst

kunnen opzetten.

Aantal gelijktijdige

dienstgebruikers

Verwijst naar het maximale aantal afzonderlijke dienstgebruikers

van een gemeente die gelijktijdig gebruik kunnen maken van de

dienst.

Maximale capaciteit

hulpbronnen

Verwijst naar de maximale hoeveelheid van een bepaalde

hulpbron (resource) die beschikbaar is voor een gemeente van de

dienst.

Hulpbronnen zijn bijvoorbeeld dataopslag, geheugen, aantal

processoren (Central Processing Units (CPU’s)).

Verwerkingscapaciteit

(throughput)

Verwijst naar het minimum aantal gespecificeerde verzoeken die

in een vastgestelde periode kunnen worden verwerkt door de

dienst. Bijvoorbeeld: het aantal verzoeken per minuut.

Opmerking: Leg duidelijk vast of het hier gaat om een minimum dienstniveaudoelstelling (het

aantal transacties kan tenminste met 5% per maand groeien) of een maximum

dienstniveaudoelstelling (bijvoorbeeld per persoon kan maximaal 1 GB data opgeslagen worden).

5.2.2. Responstijden

Hier worden de eisen met betrekking tot responstijden van het ICT-systeem en de ICT–dienst

beschreven. Op piektijden binnen drie seconden een antwoordbericht, verversen van een

webpagina en respons geven, binnen vijf seconden.

Responstijd is het tijdsinterval tussen de door de gemeente geïnitieerde gebeurtenis (stimulus) met

betrekking tot de dienst en de door de dienstleverancier geïnitieerd gebeurtenis in reactie op die

stimulus. De responstijd dienstniveaudoelstelling kan variëren afhankelijk van het moment waarop

de stimulus van de gemeente gemeten wordt. Bijvoorbeeld: de meting kan worden gestart op het

moment dat de gemeente de stimulus initieert op hun (mobiele) apparaat, of de meting kan

starten op het moment dat het verzoek van de gemeente op het eindpunt van de dienstleverancier

arriveert. Het verschil zit hem in de transporttijd over het netwerk (meestal het internet), waarop

de dienstleverancier vaak geen invloed kan uitoefenen (niet zijn verantwoordelijkheid). Evenzo kan

het punt waarop de reactie van de dienstleverancier gemeten wordt verschillen.

Page 35: voorbeeld service level agreement (sla) met aandacht voor ...

35

Responstijd is een belangrijk aspect met betrekking tot de gebruikerservaring van een dienst.

Afhankelijk van de dienstverlening kan het zijn dat als responstijden groter zijn dan een

afgesproken drempelwaarde, deze worden beschouwd als onaanvaardbaar en dat de dienst

effectief gezien onbruikbaar is. Een belangrijk aspect hierbij is dat responstijden kunnen variëren

afhankelijk van de aard van het verzoek de betreffende dienst die wordt afgenomen.

Een factor die moet worden meegenomen is dat veel diensten verschillende bewerkingen

ondersteunen en dat waarschijnlijk de responstijd voor deze verschillende bewerkingen zullen

verschillen. Het is daarom noodzakelijk om voor de dienstniveaudoelstellingen met betrekking tot

de responstijd duidelijk aan te geven om welke bewerkingen het gaat.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot responstijden

zijn:

Gemiddelde responstijd Verwijst naar het statistische gemiddelde van een verzameling

responstijden met betrekking tot een dienst voor een specifieke

bewerking (verzoek).

Maximale responstijd Verwijst naar de maximale responstijd voor een specifieke

bewerking (verzoek).

De door <dienstleverancier> ter beschikking gestelde faciliteiten

beschikken over zodanige specificaties dat <gemeente> hiermee

een responstijd kan realiseren die ruimschoots voldoende is om

via internet met de <dienst> te kunnen werken, mits de door

<gemeente> gebruikte infrastructuur voldoet aan de door

<dienstleverancier> opgegeven specificaties. Deze specificaties

zijn te vinden in de <bijlage> die bij deze SLA is bijgevoegd. De

door <dienstleverancier> kan op geen enkele manier

aansprakelijk worden gesteld voor het niet behalen van

acceptabele responstijden, indien de oorzaak hiervan is gelegen

bij de infrastructuur van <gemeente>, internetproviders of

andere derden.

Opmerking: Leg duidelijk vast of het hier om een minimum of maximum dienstniveaudoelstelling

(norm) gaat.

5.2.3. Schaalbaarheid

Hier worden de eisen met betrekking tot de schaalbaarheid van het ICT-systeem en de ICT–dienst

beschreven. Verwachte stijging van het gebruik van de dienst op middellange en lange termijn.

5.2.4. Capaciteit- en prestatierapportage

Hier worden de eisen met betrekking tot de inhoud (capaciteit en prestatie) en frequentie (interval)

van de rapportage beschreven die door de dienstleverancier worden opgeleverd. Als gemeente

dient u zicht te hebben, te krijgen en te houden op alles wat te maken heeft met de afgenomen

dienstverlening.

Page 36: voorbeeld service level agreement (sla) met aandacht voor ...

36

Voorbeelduitwerking

Met betrekking tot de rapportage moeten afspraken gemaakt worden betreffende:

De inhoud van de rapportage.

De verschijningsfrequentie.

De distributie (functionarissen, afdelingen, et cetera).

Zie ook paragraaf 4.3 Dienstrapportages.

5.3 Continuïteitseisen

Hier worden de continuïteitseisen (beschikbaarheid) met betrekking tot de dienst beschreven.

Bijvoorbeeld in het geval van een calamiteit/ramp.

Relatie met de tactische Baseline:

Bedrijfscontinuïteitsbeheer (14)

5.3.1. Hersteltermijn minimale dienstverlening

Hier wordt de termijn beschreven waarbinnen een verstoorde dienst op een (minimaal) vastgesteld

dienstverleningsniveau hersteld moet zijn. Om dit vast te stellen kan het noodzakelijk zijn dat de

gemeente een baselinetoets BIG uitgevoerd.

Voorbeelduitwerking

Voorbeeld hersteltermijn met betrekking tot de minimale dienstverlening is dat binnen één dag de

helft van de gebruikers weer moet kunnen werken met normale responstijden.

5.3.2. Hersteltermijn normale dienstverlening

Hier wordt de termijn beschreven waarbinnen een verstoorde dienst op het normale

dienstverleningsniveau hersteld moet zijn. Ook regels opnemen over escalatie (zie ook hoofdstuk

4, Communicatie tussen gemeente en dienstverlener).

Relatie met de tactische Baseline:

In contracten met externe partijen is vastgelegd hoe escalaties en aansprakelijkheid geregeld

zijn (6.2.3.6).

5.4 Beveiligingseisen

Het specificeren van meetbare beveiligingsdoelstellingen in SLA’s is nuttig om zowel de zekerheid

(assurance) als transparantie te verbeteren. Op hetzelfde moment, zorgt het voor een

gemeenschappelijke semantiek om de beveiliging van de dienst vanuit twee invalshoeken te

beheren, namelijk (i) het beveiligingsniveau dat wordt aangeboden door een dienstleverancier en,

(ii) de door een gemeente gevraagd beveiligingsniveau.

De aanpak die hierbij kan worden gebruikt is het analyseren van de beveiligingsmaatregelen van

bekende frameworks (Bijvoorbeeld ISO 27001 of de BIG) in een of meer

Page 37: voorbeeld service level agreement (sla) met aandacht voor ...

37

dienstniveaudoelstellingen. Deze dienstniveaudoelstellingen kunnen zowel kwantitatief als

kwalitatief zijn. Deze paragraaf behandelt de dienstniveaudoelstellingen die betrekking hebben op

de beveiliging van de dienst. Het aantal beschreven dienstniveaudoelstellingen is zeker niet

uitputtend, en hou ook rekening met het feit dat wellicht niet alle doelstellingen van toepassing zijn

op alle diensten.

De uitbesteding van ICT-processen mag niet leiden tot een aantasting van het bestaande

beveiligingsniveau. Uitgaand van het feit dat voorafgaand aan de uitbesteding reeds een passend

beveiligingsniveau bestond (BIG), zal dit niveau ook na de uitbesteding voortgezet moeten worden.

Uiteraard is het geen enkel probleem als de uitbesteding tot een andere of een efficiëntere

uitvoering van de beveiliging leidt. Beveiliging van systemen, diensten en data zijn hierbij

belangrijke aspecten. Deze onderdelen dienen dan ook beschermd te worden tegen zowel interne

als externe aanvallen. Zaken waar afspraken over gemaakt dienen te worden zijn:

Specifieke beveiligingsmaatregelen om de normen en afspraken uit deze SLA te halen. Denk

hierbij aan back-up/restore en encryptie/sleutelbeheer.

Procedure van beveiliging van systemen, diensten en data.

Maatregelen bij het schenden van beveiligingsprocedures.

Aanspreekpunt bij beveiligingsincidenten.

5.4.1. Betrouwbaarheid van de dienst

Betrouwbaarheid van de dienst is de eigenschap van een dienst om zijn functies correct en zonder

fouten uit te voeren, meestal over een bepaalde tijdsperiode. Deze categorie is meestal gerelateerd

aan de beveiligingsmaatregelen implementeren bedrijfscontinuïteitsbeheer en de disaster recovery

in standaarden zoals ISO 27002. Voor deze dienstniveaudoelstelling dient rekening gehouden te

worden met de toegestane downtime, die onder andere bestaat uit gepland onderhoud.

Opmerking: Betrouwbaarheid omvat ook de mogelijkheid van de dienst om op een adequate

manier om te gaan met storingen en het voorkomen van onbeschikbaarheid van de dienst of het

verlies van gegevens in het geval van dergelijke storingen.

De doelstelling met betrekking tot betrouwbaarheid moet worden vermeld, zodat de gemeente kan

beoordelen of de specifieke dienst voldoet aan hun zakelijke behoeften. Sommige databeheer

dienstniveaudoelstelling kunnen relevant zijn voor betrouwbaarheid (zie ook paragraaf 5.5).

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot de

betrouwbaarheid van de dienst zijn:

Redundantie Beschrijft de mate van redundantie van de dienst supply chain,

eventueel rekening houdend met het percentage van de

componenten of dienst die over failover mechanismen

beschikken. Redundantie varieert ook van afhankelijk van het

type dienst. Bijvoorbeeld IaaS versus SaaS.

Betrouwbaarheid van de

dienst

Beschrijft het vermogen van de dienst om zijn functie goed en

storingsvrij over een bepaalde tijdsperiode uit te voeren.

Page 38: voorbeeld service level agreement (sla) met aandacht voor ...

38

5.4.2. Authenticatie & Autorisatie

Authenticatie is de verificatie van de geclaimde identiteit van een entiteit. Bijvoorbeeld de

gebruiker van de dienst. Autorisatie is het proces van controleren of een entiteit toestemming heeft

voor toegang tot en het gebruik van een bepaalde bron op basis van vooraf gedefinieerde

gebruikersprivileges. Authenticatie en autorisatie zijn belangrijke elementen van

informatiebeveiliging die van toepassing zijn op het gebruik van diensten. De details met

betrekking tot authenticatie en autorisatie dienen duidelijk te worden beschreven door middel van

dienstniveaudoelstellingen.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot authenticatie en

autorisatie zijn:

Gebruiker authenticatie en

identiteit zekerheidsniveau

Meet de mate van zekerheid (Level of Assurance (LoA)) van het

mechanisme dat wordt gebruikt om de toegang tot een bron van

een gebruiker te verifiëren. De LoA kan worden gebaseerd op de

relevante standaarden zoals NIST SP 800-63 (Electronic

Authentication Guidelines)11, ISO/IEC 29115 (Entity

Authentication Assurance Framework)12 or the Kantara Initiative’s

Identity Assurance Framework (IAF)13.

Authenticatie Specificeert de beschikbare authenticatiemechanismen die door

de dienstleverancier worden ondersteund op de aangeboden

diensten. In sommige gevallen is het noodzakelijk dat de

gemeente samen met de dienstleverancier, de aangeboden

mechanismen analyseert op interoperabiliteit tussen de

authenticatie schema’s van de gemeente de dienstleverancier.

Bijvoorbeeld cross-certificering in het geval van digitaal certificaat

gebaseerde authenticatie).

Gemiddelde tijd om de

toegangsrechten van een

gebruiker in te trekken

Is de gemiddelde tijd die benodigd is om de toegang van

gebruikers tot de dienst in te trekken over een bepaalde

tijdsperiode.

Bescherming van de opslag

van de gebruikersrechten

Beschrijft de mechanismen die worden gebruikt om de

toegangsgegevens (credentials) van de gebruikers van de dienst

te beschermen.

Ondersteuning van

authenticatie door derden

Specificeert of authenticatie door derden wordt ondersteund door

de dienst en beschrijft welke technologieën kunnen worden

gebruikt voor authenticatie door derden.

Opmerking: Het kan zijn dat andere authenticatie

dienstniveaudoelstellingen minder relevant worden als

authenticatie wordt uitgevoerd door een derde partij.

Deze dienstniveaudoelstelling is een aanvulling op de eerder

gedefinieerde ‘Authenticatie’, en vormt de basis voor

interoperabele authenticatie/identiteit management oplossingen

11 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf 12 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45138 13 https://kantarainitiative.org/confluence/display/certification/Identity+Assurance+Accreditation+and+Approval+Program

Page 39: voorbeeld service level agreement (sla) met aandacht voor ...

39

tussen de gemeente en aanbieders.

5.4.3. Cryptografie

Cryptografie is een discipline waarin gegevens worden omgezet, teneinde de informatie-inhoud te

verbergen, te voorkomen dat deze ongemerkt wordt gewijzigd en / of zonder toestemming wordt

gebruikt. Ook bekend onder de term encryptie. Data-encryptie kan in verschillende

omstandigheden worden ingezet en er zijn er veel encryptiemethoden in gebruik en deze

methoden variëren in hun kracht en verschillen ook in hun kosten - zowel in termen van

performance en de benodigde rekenkracht. Het is noodzakelijk om in de SLA bijzonderheden met

betrekking tot betreffende encryptiemethoden te vermelden zodat de gemeente een dienst volledig

kan beoordelen.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot cryptografie zijn:

Cryptografische brute kracht

weerstand

Drukt de sterkte van een cryptografische bescherming uit op basis

van de sleutellengte. Bijvoorbeeld met de aanbevelingen van het

beveiligingsniveau ECRYPT II14 of de FIPS15 beveiligingsniveau

voor encryptie.

Opmerking: Het alleen kijken naar sleutellengte is meestal niet

voldoende omdat deze niet altijd vergelijkbaar zijn tussen de

verschillende cryptografische algoritmen.

Sleutel toegangscontrole

beleid

Beschrijft hoe sterk een cryptografische sleutel wordt beschermd

tegen toegang, wanneer deze wordt gebruikt voor de beveiliging

van de dienst.

Cryptografisch

beschermingsniveau

hardware module

Beschrijft de mate van bescherming die wordt geboden met

betrekking tot cryptografische activiteiten voor de dienst door het

gebruik van cryptografische hardware modules.

5.4.4. Incidentbeheer en rapportage

Een (informatiebeveiligings)incident is een enkele of een reeks van ongewenste of onverwachte

gebeurtenissen die een aanzienlijke kans hebben om de bedrijfsvoering te compromitteren of

verstoren en een bedreiging vormen voor de informatiebeveiliging. Incidentbeheer bestaat uit de

processen voor het detecteren, rapporteren, beoordelen, reageren op, omgaan met, en leren van

(informatiebeveiligings)incidenten. Hoe informatiebeveiligingsincidenten worden behandeld door

een dienstleverancier is van groot belang voor de gemeente, omdat een

informatiebeveiligingsincident met betrekking tot de dienst ook een informatiebeveiligingsincident

is voor de gemeente.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot incidentbeheer

zijn:

Percentage tijdige Beschrijft het percentage van de incidenten met betrekking tot de

14 http://www.ecrypt.eu.org/documents/D.SPA.20.pdf 15 csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

Page 40: voorbeeld service level agreement (sla) met aandacht voor ...

40

incidentmeldingen dienst die tijdig aan de gemeente zijn gemeld. Dit wordt

uitgedrukt als een percentage van het aantal incidenten die

binnen een vooraf vastgestelde tijdslimiet zijn gemeld na detectie,

ten opzichte van het totaal aantal incidenten met betrekking tot

de dienst binnen een vooraf bepaalde periode (bijvoorbeeld week,

maand, kwartaal, jaar, et cetera).

Percentage tijdige incident

reacties

Beschrijft het percentage van de incidenten die tijdig zijn

beoordeeld en erkend door de dienstleverancier. Dit wordt

uitgedrukt als een percentage van het aantal incidenten die

binnen een vooraf vastgestelde tijdslimiet zijn beoordeeld en

erkend door de dienstleverancier na detectie, ten opzicht van het

totaal aantal incidenten met betrekking tot de dienst binnen een

vooraf bepaalde periode (bijvoorbeeld week, maand, kwartaal,

jaar, et cetera).

Percentage tijdig opgeloste

incidenten

Beschrijft het percentage van de incidenten die tijdig zijn opgelost

door de dienstleverancier. Dit wordt uitgedrukt als een percentage

van het aantal incidenten die binnen een vooraf vastgestelde

tijdslimiet zijn opgelost door de dienstleverancier na detectie, ten

opzicht van het totaal aantal incidenten met betrekking tot de

dienst binnen een vooraf bepaalde periode (bijvoorbeeld week,

maand, kwartaal, jaar, et cetera).

Hieronder volgt een voorbeelduitwerking met betrekking tot hoe incidenten geclassificeerd kunnen

worden en wat dit voor gevolgen heeft op de reactie- en oplostijden.

Incidenten worden bij de servicedesk van de <dienstleverancier> aangemeld door de

bevoegde personen van de <gemeente>.

Een incident wordt afgesloten als het is opgelost of een door de <gemeente> geaccepteerde

workaround is geïmplementeerd waarna een ‘probleem’ wordt gecreëerd. Na implementatie

van de workaround zorgt de <dienstleverancier> ervoor dat het ‘probleem’ conform de eisen

wordt opgelost.

De classificatie van incidenten wordt bepaald door de impact en urgentie (casu quo

noodzaak). Er zijn vier (4) prioriteiten te weten prioriteit 1 (P1) t/m prioriteit 4 (P4). De

prioriteit wordt door de <gemeente> bepaald.

De classificatie van incidenten wordt bepaald door de Impact en Urgentie.

o Impact: hoe ernstig is de verstoring, hoeveel Gebruikers hebben er last van, in welke

mate wordt de continuïteit van de bedrijfsprocessen van de <gemeente> bedreigd.

o Urgentie: De mate van uitstel die de <gemeente> kan dulden, met andere woorden

hoe snel moet het probleem worden opgelost.

De volgende classificatie / prioriteiten (P) worden gehanteerd:

Impact /

urgentie

Kan niet werken

(Bedrijfskritisch)

Urgent

Kan werken

met beperkingen

(bedrijfskritisch)

Hoog

Kan werken maar

degradatie van

perfomance

(operationeel

issue)

Middel

Vraag

Laag

Prioriteit P1 P2 P3 P4

Page 41: voorbeeld service level agreement (sla) met aandacht voor ...

41

<gemeente>

o De <gemeente> bepaalt de prioriteit van het incident. Praktisch kan dit uitgevoerd

worden door bijvoorbeeld de servicedesk of de <contactpersoon> bij de <gemeente>.

o Hierbij zijn de beschikbaarheidstijden van de <contactpersoon> of de openingstijden

van de servicedesk bij de <gemeente> van belang. Binnen dit tijdswindow is in

principe melding van het incident van de < gemeente> aan de <dienstleverancier>

dus mogelijk. Maak hierover duidelijke afspraken.

o Een gemeentelijk medewerker bepaalt dus niet de prioriteit van de melding, maar kan

wel bij de interne melding aan de <contactpersoon> of servicedesk binnen de

<gemeente> zijn/haar beeld van de consequenties aangeven.

De bijbehorende reactie- en oplostijden zijn:

Prioriteit Reactietijd Oplostijd

P1 30 minuten 4 uur in

97,5% van de incidenten

P2 2 uur 8 uur in

97,5% van de incidenten

P3 4 uur 2 werkdagen in

97,5% van de incidenten

P4 2 werkdagen Best effort

Opmerking

o De oplostijd is onder andere afhankelijk van het type content en/of applicatie, de

workaround, consequenties voor de bedrijfsprocessen.

o Het kan mogelijk dat de hoogste prioriteit niet P1 maar P2 is.

5.4.5. Logging en monitoring

Logging is het vastleggen van gegevens met betrekking tot de werking en het gebruik van een

dienst. Monitoring is het vaststellen van de status van één of meer parameters van een dienst.

Logging en monitoring zijn de verantwoordelijkheid van de dienstleverancier.

Registraties (records) in logbestanden zijn belangrijk voor de gemeente bij het analyseren van

incidenten, zoals inbreuken op de beveiliging en fouten van de dienst, alsook bij het monitoren van

het dagelijkse gebruik van de dienst. Hiervoor is het noodzakelijk om dienstniveaudoelstellingen

met betrekking tot logging en monitoring van de dienst en de bijbehorende mogelijkheden volledig

te beschrijven.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot logging en

monitoring zijn:

Logging parameters Beschrijft de parameters die zijn vastgelegd in de logbestanden

van de dienst.

Toegang tot logbestanden Beschrijft tot welke gegevens (records) in de logbestanden de

gemeente toegang heeft.

Bewaartermijn logbestanden Beschrijft de tijdsperiode die logbestanden beschikbaar voor

Page 42: voorbeeld service level agreement (sla) met aandacht voor ...

42

analyse. Bijvoorbeeld de tijd die logbestanden beschikbaar zijn

voor de gemeente.

Opmerking: Voor verschillende logbestanden kunnen andere

bewaartermijnen gelden.

5.4.6. Auditing

Auditing is een systematisch, onafhankelijk en gedocumenteerd proces voor het verkrijgen van

informatie (bewijsmateriaal) over een dienst en een objectieve evaluatie hiervan om te bepalen in

welke mate aan de audit criteria wordt voldaan. De noodzakelijke informatie (bewijs) en de audit

criteria worden meestal bepaald door het audit- of certificeringschema die wordt gebruikt om de

audit uit te voeren. Audits zijn een middel waarmee de dienstleverancier kan aantonen dat een

dienst voldoet aan bepaalde criteria die van belang zijn voor de gemeente op basis van

onafhankelijk verkregen bewijs. Audits zijn er op gericht om het vertrouwen in de dienst te

verhogen.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot auditing zijn:

Certificaten van toepassing Verwijst naar een lijst van certificaten die in het bezit zijn van de

dienstleverancier voor een dienst, inclusief de certificerende

instantie, de vervaldatum van elke certificering en de

verlengingsperiode.16

5.4.7. Vulnerability management

Een kwetsbaarheid is een zwakke plek in een informatiesysteem, beveiligingsprocedures van het

systeem, interne controles, of de implementatie die kan worden misbruikt door een bedreiging. Het

beheer van kwetsbaarheden betekent dat informatie over technische kwetsbaarheden van

informatiesystemen die wordt gebruikt tijdig moet worden verkregen en de blootstelling aan

dergelijke kwetsbaarheden dient te worden geëvalueerd en er dienen passende maatregelen

genomen te worden om de bijbehorende risico’s te beperken. De dienstleverancier is in veel

gevallen de eigenaar van de informatiesystemen die zijn geassocieerd met een dienst met als

gevolg dat de gemeente afhankelijk is van de dienstleverancier voor het juiste en tijdige beheer

van de kwetsbaarheden voor deze informatiesystemen. De dienstniveaudoelstellingen met

betrekking tot vulnerability management dienen hierin transparantie voor de gemeente te bieden.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot vulnerability

management zijn:

Percentage tijdig herstelde

kwetsbaarheden

Beschrijft het aantal kwetsbaarheden die door de

dienstleverancier zijn hersteld. Dit wordt uitgedrukt als een

percentage van het aantal kwetsbaarheden die door de

dienstleverancier tijdig zijn hersteld, ten opzichte van het totaal

aantal kwetsbaarheden die voor de dienst zijn hersteld en binnen

16 Bijvoorbeeld de ENISA’s cloud certificeringschema (https://resilience.enisa.europa.eu/cloud-computing-certification)

Page 43: voorbeeld service level agreement (sla) met aandacht voor ...

43

een vooraf bepaalde periode zijn gemeld (bijvoorbeeld week,

maand, kwartaal, jaar, et cetera).

Percentage tijdige

kwetsbaarheidsmeldingen

Beschrijft het aantal kwetsbaarheidsmeldingen die door de

dienstleverancier naar de gemeente zijn verstuurd. Dit wordt

uitgedrukt als een percentage van het aantal

kwetsbaarheidsmeldingen die door de dienstleverancier tijdig zijn

verstuurd, ten opzichte van het totaal aantal

kwetsbaarheidsmeldingen die voor de dienst binnen een vooraf

bepaalde periode zijn verstuurd (bijvoorbeeld week, maand,

kwartaal, jaar, et cetera).

Rapportages van herstelde

kwetsbaarheden

Is een beschrijving van het mechanisme waarmee de

dienstleverancier de gemeente informeert over de

kwetsbaarheden die zijn hersteld op de informatiesystemen van

de dienstleverancier, inclusief de frequentie van de rapportages.

5.5 Databeheer

Het beheren van gegevens en informatie in het tijdperk van Cloud Computing en maar ook

uitbesteding heeft gevolgen voor alle organisaties. De databeheer dienstniveaudoelstellingen in dit

hoofdstuk worden uitgedrukt in kwantitatieve en kwalitatieve indicatoren die betrekking hebben op

de databeheer levenscyclus, en kan worden beschouwd als een aanvulling op de bestaande en van

toepassing zijnde beveiliging en gegevensbescherming die wordt aangeboden door de

dienstleverancier.

De databeheer dienstniveaudoelstellingen zijn onderverdeeld in vier (4) verschillende categorieën

die alle aspecten van de geïdentificeerde data levenscyclus behandelen. Niet alle

dienstniveaudoelstellingen zijn relevant voor elke dienst, dit is met name afhankelijk van het type

dienst. Voor Cloud geldt dit voor de volgende verschillende typen: IaaS, PaaS of SaaS.

5.5.1. Afscherming van gegevens

Het is voor de gemeente van groot belang om afspraken te maken over de wijze waarop met zijn

gegevens wordt omgegaan. De beveiligingseisen zijn hier primair gericht op de vertrouwelijkheid

en in mindere mate de integriteit van de gebruikersgegevens. De dienstleverancier zal zowel

binnen de verwerkingsorganisatie als voor de afscherming van de applicatie gebruik dienen te

maken van afdoende logische toegangsbeveiliging. Als aanvullende eis zou door de gemeente

gesteld kunnen worden dat de logische toegangsbeveiliging jaarlijks door een deskundige en

onafhankelijke auditor dient te worden gecontroleerd.

Eisen met betrekking tot het afschermen van gegevens in de SLA betreffen onder andere:

Classificatie van gegevens

Integraal systeem van logische beveiliging

Rapportage van inbreuken

Periodieke audit van de logische toegangsbeveiliging

Page 44: voorbeeld service level agreement (sla) met aandacht voor ...

44

5.5.2. Dataclassificatie

Dataclassificatie is een beschrijving van gegevensklassen die zijn geassocieerd met de dienst:

Gemeentelijke gegevens

Gegevens van de dienstleverancier

Gegevens afgeleid van de dienst

Gemeentelijke gegevens is een gegevensklasse die onder de controle is van de gemeente.

Gemeentelijke gegevens omvatten gegevens die door de gemeente zijn ingevoerd in de dienst

maar ook de resultaten die voortkomen uit het gebruik van de dienst door de gemeente.

Voorbeelduitwerking

De volgende dienstniveaudoelstellingen bevatten een specifiek overzicht van data toepassingen

(leverancier en afgeleide), die kunnen worden gebruikt om verschillende dienstleveranciers te

vergelijken. Gemeenten kunnen deze informatie gebruiken om weloverwogen een beslissingen te

nemen over de keuze van hun dienstleverancier.

Het gebruik van

gemeentelijke gegevens door

de dienstleverancier

Beschrijft het beleid van de dienstleverancier van het

voorgenomen gebruik van de gemeentelijke gegevens.

Het gebruik van dienst

afgeleide gegevens

Beschrijft welke afgeleide gegevens worden gecreëerd door de

dienstleverancier uit de gemeentelijke gegevens, het

voorgenomen gebruik van de afgeleide gegevens en welke

rechten de gemeente heeft om de afgeleide gegevens te

inspecteren.

5.5.3. Gegevens mirroring, back-up & restore

Deze dienstniveaudoelstellingen categorie gaat over de mechanismen die worden gebruikt om te

garanderen dat de gemeentelijke gegevens beschikbaar zijn (online of offline). De mechanismen

die binnen dit toepassingsgebied van deze dienstniveaudoelstelling vallen zijn verdeeld in twee veel

gebruikte categorieën (i) data mirroring, (ii) back-up / restore.

Veel gebruikte beveiligingscertificeringen bevatten specifieke beveiligingsmaatregelen die worden

uitgevoerd om gegevensverlies te voorkomen. In veel gevallen bevatten deze zelden

mogelijkheden die door de gemeente kunnen worden gebruikt om te beoordelen/controleren of de

geïmplementeerde beveiligingsmaatregelen daadwerkelijk aan haar eisen voldoen. In het bijzonder

met betrekking tot dienstniveaudoelstellingen op de volgende gebieden:

De tijdigheid (actualiteit) van de mirroring mechanismen, die wellicht rechtstreeks verband

heeft met de geografische ligging van de datacenters van de dienstleverancier.

Concrete gegevens in verband met de frequentie en de methode die door de back-up en

recovery-mechanismen van de dienstleverancier worden gebruikt.

Voorgestelde dienstniveaudoelstellingen stellen gemeenten in staat om bijvoorbeeld hun

procedures voor risicobeoordeling en bedrijfscontinuïteit bij te stellen.

De dienstniveaudoelstellingen kan de gemeente helpen bij het opzetten van Recovery Point

Objective (RPO)17 and Recovery Time Objective (RTO) 18 bij gebruik van de dienst.

17 RPO duidt op de maximale toegestane tijd (termijn) van gegevensregistratie die de organisatie bereid is kwijt te spelen naar aanleiding van een crash. Bij een dagelijkse back-up van de gegevens zal de RPO dus 24 uur

Page 45: voorbeeld service level agreement (sla) met aandacht voor ...

45

RPO is de maximaal toegestane tijd tussen herstelpunten. RPO specificeert niet de hoeveelheid

acceptabel gegevensverlies, alleen de acceptabele tijdsperiode. In het bijzonder, RPO beïnvloedt

redundantie van gegevens en back-up. Een kleine RPO suggereert mirroring opslag van zowel

tijdelijke als permanente gegevens, terwijl bij een grotere tijdsperiode een periodieke back-up

benadering mogelijk is. Zoals met RTO, dient de gemeente hun aanvaardbare RPO te bepalen voor

iedere dienst die ze gebruiken en ervoor te zorgen dat de dienstleverancier en hun eigen disaster

recovery plan (rampenherstelplannen), voldoen aan hun doelstellingen. RTO is de maximale

hoeveelheid tijd dat een bedrijfsproces kan worden verstoord, na een ramp, zonder

onaanvaardbare gevolgen voor de bedrijfsvoering. Diensten kunnen kritische componenten zijn

voor de bedrijfsprocessen. Gemeenten moeten de RTO bepalen voor elk bedrijfsproces dat

afhankelijk is van de dienst en tevens moeten ze bepalen of de disaster recovery plannen

(rampenherstelplannen) van de dienstleverancier en hun eigen voldoen aan hun doelstellingen.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot data mirroring,

back-up / restore zijn:

Gegevens mirroring latency Verwijst naar het verschil tussen de tijd dat gegevens op het

primaire opslagmedium wordt opgeslagen en de tijd dat dezelfde

gegevens op een gespiegeld opslagmedium wordt geplaatst.

Data back-up methode Verwijst naar een overzicht van de methoden die gebruikt kunnen

worden om gemeentelijke gegevens te back-uppen.

Data back-up frequentie Verwijst naar de tijdsperiode tussen twee volledige back-ups van

de gemeentelijke gegevens.

Back-up retentie periode Verwijst naar de tijdsperiode dat een bepaalde back-up

beschikbaar blijft voor dataherstel, alvorens deze verwijderd

wordt.

Back-up generaties Verwijst naar het aantal back generaties die beschikbaar zijn voor

dataherstel.

Maximale gegevens

hersteltijd

Verwijst naar de maximale tijd die nodig is om gemeentelijke

gegevens vanaf een back-up terugzetten.

Percentage succesvolle

dataherstel

Verwijst naar het percentage waarbij het dataherstel succesvol is

uitgevoerd. Het aantal dataherstel acties die zonder fouten zijn

uitgevoerd voor de gemeente ten opzichte van het totaal aantal

uitgevoerde dataherstel acties, uitgedrukt als percentage.

5.5.4. Datalevenscyclus

Het volgende overzicht van dienstniveaudoelstellingen is gerelateerd aan de efficiëntie en

effectiviteit van de werkwijze met betrekking tot de datalevenscyclus19 door dienstleverancier, met

een bijzondere aandacht voor de werkwijze en mechanismen voor het verwerken en verwijderen

van data. Aan de ene kant, geeft het volgende overzicht van dienstniveaudoelstellingen informatie

bedragen, omdat bij een totaal verlies alleen de gegevens die de dag voordien werden opgeslagen, beschikbaar zullen zijn. 18 RTO staat voor de maximale duur van de onderbreking van het computersysteem die een organisatie bereid is te accepteren in het geval van een crash. De RTO zal enerzijds afhangen van de snelheid waarmee het geïnstalleerde back-upsysteem de gegevens kan herstellen en anderzijds van het soort toepassingen dat door de crash werd getroffen. 19 proces van creëren, verzamelen, toegankelijk maken, aanpassen, opslaan, verwijderen en archiveren van data

Page 46: voorbeeld service level agreement (sla) met aandacht voor ...

46

in verband met de garanties (assurance) en actualiteit in verband met de mechanismen voor het

verwijderen van gegevens. Anderzijds, worden ook kwantitatieve dienstniveaudoelstellingen

beschreven in verband met de betrouwbaarheid van de dienstverlening met betrekking tot

dataopslag (het ophalen/-vragen en de duurzaamheid van de opgeslagen gegevens). Verder kan

het van belang zijn voor de gemeente dat deze in staat is om gegevens op te halen/vragen nadat

een verwijder verzoek is ingediend. Hiervoor dienen dan ook dienstniveaudoelstellingen voor

worden vastgelegd.

Voorbeelduitwerking

Gemeenten kunnen onderstaand overzicht gebruiken om bijvoorbeeld een besluit te nemen over

welk beschikbaar opslagmechanisme wordt gekozen die door de dienstleverancier worden

aangeboden.

Data verwijderingstechniek Beschrijft de kwaliteit van de verwijderingstechnieken om data te

verwijderen. Van ‘zwakke’ verwijderingstechnieken ,waar alleen

de verwijzing naar de data wordt verwijderd, tot ‘sterke’

verwijderingstechnieken zodat het terughalen van de verwijderde

gegevens haast onmogelijk is.20

Percentage effectief

uitgevoerde

verwijderverzoeken

Verwijst naar het aantal verwijderverzoeken van de gemeente die

zijn voltooid binnen een vooraf bepaalde tijdslimiet ten opzichte

van het totaal aantal uitgevoerde verwijderverzoeken, uitgedrukt

als percentage.

Percentage van geteste

terughaalbare opslag

Verwijst naar de hoeveelheid gemeentelijke gegevens waarvan is

geverifieerd dat deze tijdens de meetperiode terug te halen zijn,

nadat de gegevens waren gewist.

Restore na vastgestelde

bewaartermijn

Data die weggegooid / verwijderd is wordt gedurende een

bepaalde termijn bewaard. Op verzoek van de <gemeente> kan

na afloop van deze bewaartermijn de verwijderde data

teruggehaald worden (recovery) mits deze data nog beschikbaar

is.

5.5.5. Gegevensoverdraagbaarheid (dataportabiliteit)

Het volgende overzicht met dienstniveaudoelstellingen is gerelateerd met de mogelijkheden van de

dienstleverancier om gegevens te exporteren, zodat deze gegevens nog steeds door de gemeente

kunnen worden gebruikt bijvoorbeeld in het geval van contractbeëindiging. Vaak richten de

beveiligingsmaatregelen zich bij dataportabiliteit op het van toepassing zijnde beleid van de

dienstleverancier. Hierdoor is het moeilijk (en soms onmogelijk) voor de gemeente om de

specifieke indicatoren in verband met de beschikbare formaten, interfaces en

overdrachtssnelheden te achterhalen.

Voorbeelduitwerking

Het volgende overzicht met dienstniveaudoelstellingen richt zich op deze drie fundamentele

aspecten van dataportabiliteit, die kunnen worden gebruikt door de gemeente. Bijvoorbeeld om

over de technische voorzieningen met trekking tot het beëindigingsproces van de

dienstleverancier te onderhandelen.

20 Zie voor meer informatie NIST Special Publication 800-88: Guidelines for Media Sanitization (http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_with-errata.pdf)

Page 47: voorbeeld service level agreement (sla) met aandacht voor ...

47

Formaat dataportabiliteit Specificeert het digitale formaat waarin de gemeentelijke

gegevens kunnen worden overgezet naar of benaderd vanuit de

dienst.

Interface dataportabiliteit Specificeert de mechanismen die kunnen worden gebruikt om

gemeentelijke gegevens van en naar de dienst te over te

brengen.

Dit omvat onder andere specificaties van transportprotocollen,

Application Programming Interfaces (APIs) of enig ander

mechanisme dat wordt ondersteund.

Overdrachtssnelheid Verwijst naar de minimale snelheid waarmee gemeentelijke

gegevens kunnen worden overgebracht naar/van de dienst met

behulp van het mechanismen vermeld in de interface

dataportabiliteit.

5.6 Bescherming persoonsgegevens

Deze paragraaf richt zich op het vaststellen van passende dienstniveaudoelstellingen met

betrekking tot die situaties waarbij de dienstleverancier als een gegevensverwerker (bewerker)

fungeert, namens de gemeente (verantwoordelijke).

Hierbij is de Wet bescherming persoonsgegevens (Wbp) van cruciaal belang.21 Op 10 februari 2015

is met algemene stemmen het wetsvoorstel meldplicht datalekken en uitbreiding bestuurlijke

boetebevoegdheid College bescherming persoonsgegevens (Cbp) aangenomen door de Tweede

Kamer. 22 Dit wetsvoorstel voegt aan de Wbp een meldplicht voor inbreuken op

beveiligingsmaatregelen voor persoonsgegevens toe. Met de meldplicht datalekken wil de regering

de gevolgen van een datalek voor de betrokkenen zoveel mogelijk beperken en hiermee een

bijdrage leveren aan het behoud en herstel van vertrouwen in de omgang met persoonsgegevens.

Met dit voorstel dient de verantwoordelijke bij een datalek, waarbij kans is op verlies of

onrechtmatige verwerking van persoonsgegevens, niet alleen een melding te doen bij de

toezichthouder, het Cbp, maar ook de betrokkene te informeren. Deze meldplicht geldt voor alle

verantwoordelijken voor de verwerking van persoonsgegevens, zowel in de private als publieke

sector. Als er geen melding wordt gemaakt van een datalek kan dit bestraft worden met een

bestuurlijk boete van het Cbp.

In dit verband dient te worden vermeld dat er ook een Europees initiatief is van de C-SIG Code of

Conduct subgroep voor de ‘Data Protection Code of Conduct for Cloud service providers’.23

5.6.1. Gedragscodes, normen, standaarden en certificeringen

De gemeente, als verantwoordelijke voor de verwerking, moet de verantwoordelijkheid voor het

naleven van de toepasselijke wetgeving inzake gegevensbescherming accepteren. Met name heeft

de gemeente de plicht om de rechtmatigheid van de verwerking van persoonsgegevens te

beoordelen en een dienstleverancier te selecteren die de naleving van de toepasselijke wetgeving

begeleid/faciliteert.

21 Zie http://www.eerstekamer.nl/wetsvoorstel/25892_wet_bescherming 22 Het voorstel (EK 33.662, A) is op 10 februari 2015 met algemene stemmen aangenomen door de Tweede Kamer. Zie http://www.eerstekamer.nl/behandeling/20150210/gewijzigd_voorstel_van_wet 23 Zie https://ec.europa.eu/digital-agenda/en/cloud-select-industry-group-code-conduct

Page 48: voorbeeld service level agreement (sla) met aandacht voor ...

48

In dit verband dient de dienstleverancier alle noodzakelijke informatie beschikbaar te stellen, ook

in het kader met betrekking tot de naleving van het principe van transparantie, zoals hierna

beschreven. Dergelijke informatie omvat informatie die kan helpen bij de beoordeling van de

dienst, zoals gedragscodes met betrekking tot de bescherming van persoonsgegevens, normen of

certificeringsregelingen waar de dienst aan voldoet.

Voorbeelduitwerking

In het kader van de hierboven genoemde verplichtingen, is de hierna vermelde informatie nuttig

zodat de gemeente de dienst op het niveau van naleving van de geldende regelgeving kan

beoordelen. Voorbeelden van relevante dienstniveaudoelstellingen zijn:

Van toepassing zijnde

gedragscodes, normen,

standaarden en

certificeringen

Een overzicht van gedragscodes, standaarden, normen en

certificeringen waar de dienst met betrekking tot

gegevensbescherming aan voldoet.24

5.6.2. Doelbinding

Het principe van doelbinding vereist dat persoonsgegevens alleen worden verwerkt ten behoeve

van welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden en vervolgens niet

worden verwerkt op een wijze die onverenigbaar is met de vastgestelde doelbinding. Hieraan

gekoppeld zijn verplichtingen tot dataminimalisatie, zorg voor de kwaliteit van gegevens,

terughoudendheid met verdere verwerking en een beveiligingsverplichting. Daarom dient het doel

van de verwerking voorafgaand aan het verzamelen van persoonsgegevens te worden vastgesteld

voor de verwerking door de verantwoordelijke, die tevens de betrokkene daarvan op de hoogte

dient te stellen.

Wanneer de verantwoordelijke besluit om de data extern te verwerken, dient ervoor te worden

gezorgd dat persoonsgegevens niet (illegaal) voor andere doeleinden worden verwerkt door de

dienstleverancier, of één van zijn onderaannemers.

In het algemeen mag de dienstleverancier geen persoonsgegevens, op grond van de overeenkomst

met de gemeente, voor eigen doeleinden, zonder de uitdrukkelijke toestemming van de gemeente

verwerken. Een dienstleverancier die persoonsgegevens van de gemeente voor eigen doeleinden

verwerkt, zonder een expliciet mandaat van de gemeente (bijvoorbeeld om een markt of

wetenschappelijke analyse uit te voeren of om de direct marketing te verbeteren, alles uit

eigenbelang), kwalificeert zich als een verantwoordelijke voor de gegevensverwerking in

eigenbelang en zal daarom aan alle relevante verplichtingen dienen te voldoen.

Het is daarom belangrijk dat het overzicht met verwerkingsdoeleinden (indien aanwezig), die niet

door de gemeente zijn gewenst/geëist, is gedefinieerd.

Voorbeelduitwerking

Voorbeelden van relevante dienstverleningsniveaus (doelstellingen) in relatie tot doelbinding zijn:

Verwerkingsdoeleinden Een overzicht met verwerkingsdoeleinden (indien aanwezig) die

buiten de door de gemeente als verantwoordelijke zijn

gewenst/geëist.

24 Dit omvat bijvoorbeeld de Wet bescherming persoonsgegevens (Wbp), EU Data Protection Code of Conduct for Cloud service providers en de ISO / IEC 27018 ‘Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors’, een internationale standaard voor de verwerking van persoonsgegevens in de Cloud, et cetera.

Page 49: voorbeeld service level agreement (sla) met aandacht voor ...

49

5.6.3. Dataminimalisatie

De gemeente is verantwoordelijk en dient zich ervan te verzekeren, dat persoonsgegevens worden

gewist (door de dienstleverancier en eventuele onderaannemers), waar ze ook zijn opgeslagen,

zodra deze niet meer nodig zijn voor de specifieke doeleinden. Verder kan het voorkomen dat

tijdelijke gegevens worden aangemaakt op het moment dat gebruik wordt gemaakt van de dienst,

en dat deze om technische redenen niet onmiddellijk kunnen worden verwijderd op het moment

dat ze niet meer worden gebruikt. Periodieke controles dienen aan te tonen (garanderen) dat

dergelijke tijdelijke gegevens effectief zijn verwijderd na een vooraf bepaalde periode.

Het contract tussen de gemeente en de dienstleverancier dient duidelijke bepalingen voor het

wissen van persoonsgegevens te bevatten.25 Aangezien (persoons)gegevens redundant op

verschillende servers op verschillende locaties bewaard kunnen worden, moet men zeker zijn dat

elk exemplaar daarvan onherroepelijk wordt gewist. Bijvoorbeeld eerdere versies, tijdelijke

bestanden, et cetera.

Voorbeelduitwerking

De volgende dienstniveaudoelstellingen dienen vertaald te worden naar meetbare doelstelling die

van toepassing zijn op de principes van dataminimalisatie en in lijn zijn met de dienst.

Bewaartermijn tijdelijke

gegevens

De maximale tijdsperiode dat tijdelijk gegevens worden bewaard

na vaststelling dat deze tijdelijke gegevens niet meer wordt

gebruikt.

Gemeentelijke gegevens

bewaringstermijn

De maximale tijdsperiode dat gemeentelijke gegevens worden

bewaard, voordat deze worden vernietigd door de

dienstleverancier en na een bevestiging door de gemeente van

het verzoek om de gegevens te verwijderen of de beëindiging van

het contract.

5.6.4. Gebruiksbeperkingen

De dienstleverancier, in haar hoedanigheid als gegevensverwerker (bewerker), dient de gemeente

op de meest doelmatige wijze te informeren over een (juridisch bindend) overheidsverzoek om

gebruikersinformatie (persoonsgegevens) in verband met een strafonderzoeken. Hierbij is de

dienstleverancier verplicht om deze gegevens aan de rechtshandhaving of overheidsinstantie

beschikbaar te stellen, tenzij anders is verboden, zoals een wettelijk verbod om de

vertrouwelijkheid van het onderzoek te behouden.

Voorbeelduitwerking

Naast de hierboven genoemde verplichting om de gemeente te informeren, hebben de volgende

dienstniveaudoelstellingen tot doel de informatieverschaffing aan de

rechtshandhavingsautoriteiten gedurende een tijdsperiode te kwantificeren. Dit biedt de gemeente

tevens de mogelijkheid om meerdere aanbiedingen van verschillende dienstleveranciers te

vergelijken.

Aantal rechtshandhaving

informatieverstrekkingen

Verwijst naar het aantal informatieverstrekkingen van

persoonsgegevens aan rechtshandhavingsautoriteiten gedurende

25 Bijvoorbeeld Article 29 Working Party Opinion no. 5/2012 on Cloud Computing http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp196_en.pdf

Page 50: voorbeeld service level agreement (sla) met aandacht voor ...

50

gemeentelijke gegevens een vooraf bepaalde tijdsperiode. Dit is alleen van toepassing als

de verstrekking van dergelijke informatie wordt toegestaan door

de wet.

Aantal meldingen

informatieverstrekkingen

persoonsgegevens

Verwijst naar het aantal informatieverschaffing van

persoonsgegevens aan rechtshandhavingsautoriteiten die

daadwerkelijk aan de gemeente zijn gemeld, gedurende een

vooraf bepaalde tijdsperiode. Dit is alleen van toepassing als de

verstrekking van dergelijke informatie wordt toegestaan door de

wet.

5.6.5. Openheid, transparantie en kennisgeving

Alleen als de dienstleverancier de gemeente informeert over alle relevante26 kwesties, is de

gemeente in staat om te voldoen aan haar verplichtingen als verantwoordelijke met betrekking tot

de verwerking van persoonsgegevens om de rechtmatigheid van deze verwerking te beoordelen.

Bovendien dient de dienstleverancier de informatie beschikbaar te stellen, die de gemeente in staat

stelt om de betrokkenen te voorzien van een adequate kennisgeving met betrekking tot de

verwerking van hun persoonsgegevens. Zoals door de wet is vereist.

Transparantie betekent onder andere dat de gemeente bewust wordt gemaakt van het feit dat de

dienstleverancier gebruik maakt van onderaannemers om de betreffende dienst aan te kunnen

bieden.

Met betrekking tot de overdracht van persoonsgegevens van de gemeente naar de

onderaannemers van de dienstleverancier, benadrukt de WP 29 Opinion de noodzaak dat de

contracten tussen de dienstleverancier en haar onderaannemers, de bepalingen inzake de

gegevensbescherming weerspiegelen, zoals opgenomen in het contract tussen de gemeente en

dienstleverancier.

Bovendien is toestemming van de gemeente noodzakelijk (die kan zijn vormgegeven in een

voorafgaande algemene toestemming) voor het gebruik van onderaannemers en kan de gemeente

zich verzetten tegen veranderingen in de lijst met onderaannemers.27 Om deze bepalingen uit te

voeren, dient de lijst van onderaannemers ter beschikking te worden gesteld aan de gemeente.

De verwerking van bepaalde bijzondere gegevenscategorieën kan de naleving van specifieke

wettelijke bepalingen eisen, die niet worden gedekt door algemene normen of certificeringen.

Daarom dient duidelijk binnen de SLA te worden bepaald voor welke bijzondere

gegevenscategorieën de dienst geschikt is.

Lijst met tier-1

onderaannemers

Verwijst naar onderaannemers van de dienstleverancier, die

betrokken zijn bij de verwerking van persoonsgegevens van de

gemeente.

Bijzondere gegevens

categorieën

Verwijst naar de lijst van specifieke gegevenscategorieën (indien

aanwezig) waarvoor de dienst geschikt is om te verwerken,

volgens de geldende normen, voorschriften en wet- en

26 De dienstleverancier zal moeten inschatting of de kwestie relevant is voor de gemeente of niet, de gemeente is hierbij dus afhankelijk van de inschatting van haar dienstleverancier. Maakt de dienstleverancier een verkeerde inschatting, dan kan dit (grote) gevolgen hebben voor de gemeente. Denk bijvoorbeeld aan de meldplicht datalekken (https://www.eerstekamer.nl/wetsvoorstel/33662_meldplicht_datalekken_en) 27 Let hierbij goed op dat dit niet resulteert in een leverancier lock-in. Biedt de leveranciers de mogelijkheid om te kunnen migreren naar een andere leverancier. Als dit niet het geval is bestaat het risico dat men, met een eenmaal gemaakte keuze, voor langere tijd vastzit aan die leverancier en dat het lastig wordt om diensten te verhuizen.

Page 51: voorbeeld service level agreement (sla) met aandacht voor ...

51

regelgeving. Bijvoorbeeld gezondheid of financieel gerelateerde

gegevens of anderszins gevoelige gegevens,

5.6.6. Verantwoording

Op het gebied van gegevensbescherming, heeft verantwoording vaak een brede betekenis en

beschrijft het vermogen van partijen om aan te tonen dat zij passende maatregelen hebben

genomen om de bescherming van gegevens te garanderen.

In deze context is het afleggen van verantwoording vooral van belang om lekken van

persoonsgegevens te onderzoeken. De ICT-infrastructuur dient hiervoor betrouwbare logging en

monitoring mechanismen te bieden, zoals beschreven in de desbetreffende paragraaf 5.4.5 van

deze SLA.

Bovendien dienen dienstleveranciers bewijsstukken te kunnen overleggen dat ze passende en

doeltreffende maatregelen hebben genomen die de beginselen met betrekking tot

gegevensbescherming ondersteunen. Bijvoorbeeld procedures om de identificatie van alle

gegevensverwerkingen te verzekeren, om adequaat op toegangsverzoeken te reageren, het

aanstellen van een functionaris gegevensbescherming (data privacy officer), et cetera. Zowel

gemeenten als de verantwoordelijken voor de gegevensverwerking, dienen in staat te zijn om de

opzet en bestaan, mogelijk ook de werking, van de noodzakelijke maatregelen aan bevoegde

toezichthoudende autoriteiten te tonen.

De dienstleverancier dient de gemeente op de hoogte te brengen als er een datalek heeft

plaatsgevonden en dit invloed (impact) heeft op de gemeentelijke gegevens. Daartoe dient de

dienstleverancier over een beleid op het gebied van datalekken te beschikken waarin de

procedures voor het vaststellen van en communiceren over datalekken is beschreven.

Voorbeelduitwerking

In dit verband, implementeert de eerste dienstniveaudoelstelling deze principes en biedt de

gemeente de mogelijkheid om het beleid van de dienstleverancier te evalueren.

De tweede dienstniveaudoelstelling heeft betrekking op de noodzaak om voorbereid te zijn om de

opzet en bestaan, mogelijk ook de werking, van de noodzakelijke maatregelen aan bevoegde

toezichthoudende autoriteiten op verzoek te tonen.

Beleid lekken

persoonsgegevens

Beschrijft het beleid van de dienstleverancier met betrekking tot

datalekken.

Documentatie Verwijst naar het overzicht met documenten die de

dienstleverancier beschikbaar stelt, om de naleving op de eisen

en verplichtingen met betrekking tot gegevensbescherming aan te

tonen. Bijvoorbeeld procedures om op toegangsverzoeken te

reageren, vaststellen functionarissen voor gegevensbescherming,

certificeringen, et cetera.

5.6.7. Geografische locatie van gegevens

Persoonsgegevens die worden verwerkt door uitbesteding kunnen worden overgedragen naar

derde landen, waarvan de wetgeving niet een adequaat niveau van gegevensbescherming

garandeert. Dit impliceert ook dat persoonsgegevens kunnen worden verstrekt aan buitenlandse

wetshandhavingsdienst zonder geldige EU-rechtsgrond.

Page 52: voorbeeld service level agreement (sla) met aandacht voor ...

52

Om deze risico's te minimaliseren, dient de gemeente te controleren of de dienstleverancier de

rechtmatigheid van de grensoverschrijdende overdracht van gegevens garandeert. Bijvoorbeeld

door de beveiliging van dergelijke gegevensoverdrachten te borgen door middel van safe harbour

overeenkomsten/regelingen, EC-modelclausules of bindende bedrijfsvoorschriften, naargelang de

situatie.

Daartoe zal de gemeente geïnformeerd dienen te worden over de locatie waar de gegevens

verwerkt worden, zoals ook vereist in de hierboven genoemde beginselen van openheid en

transparantie.

Voorbeelduitwerking

De volgende dienstniveaudoelstellingen geven de instrumenten op basis waarvan de gemeente is

toegestaan om de locatie van de gegevens beheren.

Overzicht geolocatie

gegevens

Specificeert de geografische locatie(s) waar de gemeente

gegevens kunnen worden opgeslagen en verwerkt door de

dienstleverancier.

Selectie geolocatie gegevens Specificeert of de gemeente een geografische locatie kan kiezen

voor de opslag van de gemeentelijke gegevens.

5.6.8. Interventies

De Wbp, gebaseerd op de databeschermingsrichtlijn 95/46/EG van het Europees Parlement, geeft

de betrokkene het recht van toegang, correctie, wissen, blokkeren en bezwaar. Daarom dient de

gemeente te controleren of de dienstleverancier geen technische en organisatorische obstakels

opwerpt met betrekking tot deze eisen, ook in gevallen dat de gemeentelijk gegevens verder

worden verwerkt door onderaannemers.

Het contract tussen de gemeente en de dienstleverancier dient te beschrijven dat de

dienstleverancier verplicht is om de gemeente op een tijdige en efficiënte wijze te ondersteunen bij

het uitvoeren van de rechten van de betrokkene.

Voorbeelduitwerking

De volgende dienstniveaudoelstelling streeft ernaar om een objectieve basis te definiëren voor

deze activiteiten.

Toegangsverzoek responstijd Verwijst naar de tijdsperiode waarbinnen de dienstleverancier

over de benodigde gegevens dient te communiceren, zodat de

gemeente kan reageren op toegangsverzoeken van de

betrokkenen.

5.7 Performanceniveau

In de vorige paragrafen zijn de prestatie-eisen welke aan de te leveren diensten gesteld worden,

beschreven. Om vast te stellen of beide partijen zich aan de overeengekomen afspraken houden,

dient de dienstverlening gemeten te worden. Elke prestatie-eis dient vertaald te worden in één of

meer kritieke/kritische prestatie-indicatoren (KPI). Vervolgens dient voor elke KPI een norm

bepaald te worden, die niet overschreden mag worden. De KPI’s dienen toetsbaar te zijn, dat wil

zeggen dat ze aan een aantal eisen dienen te voldoen, zoals:

Page 53: voorbeeld service level agreement (sla) met aandacht voor ...

53

Validiteit: De prestatie-indicator dient een maat te zijn voor de prestatie(eis) waarin inzicht

nodig is.

Geldigheid: De prestatie-indicator dient toepasbaar te zijn in de situatie waarin deze toegepast

wordt.

Eenduidigheid: De prestatie-indicator dient slechts op één manier geïnterpreteerd te kunnen

worden.

Meetbaarheid: De meetwaarden van de prestatie-indicator dienen kwantitatief te bepalen te

zijn (er moet een meetschaal voor de indicator zijn).

Vergelijkbaarheid: De meetwaarden van dezelfde prestatie-indicator in verschillende situaties

dienen vergelijkbaar te zijn. Uiteindelijk dient er voor iedere prestatie-indicator een norm

bepaald te worden, oftewel een waarde die niet overschreden mag worden. Een norm kan een

minimum zijn (bijvoorbeeld voor beschikbaarheid), of een maximum (bijvoorbeeld voor

vertraging).

Page 54: voorbeeld service level agreement (sla) met aandacht voor ...

54

6 Taken en verantwoordelijkheden

Uitbesteden van ICT-processen leidt slechts tot een overdracht van taken en

verantwoordelijkheden. De eindverantwoordelijkheid voor de ICT-processen, inclusief de

beveiligingsaspecten, kan niet worden overgedragen. Ook de ICT-processen die zijn uitbesteed,

blijven verbonden met de gemeente. De kwaliteit van het uitbestede ICT-proces en de producten

die daaruit voortvloeien, behouden een directe invloed op het functioneren van de gemeentelijke

bedrijfsprocessen.

Uitbesteding leidt in eerste instantie tot een reductie van ICT-processen en de daaraan verbonden

werkzaamheden. De totstandkoming van een uitbestedingsrelatie tussen de gemeente en

dienstleverancier leidt echter ook tot het ontstaan van nieuwe beheertaken. De uitbesteding van

een ICT-proces leidt er in ieder geval toe dat de directe operationele werkzaamheden rond het

proces op de dienstleverancier overgaan. In het verlengde daarvan dient er echter een

gemeentelijke beheerorganisatie ingericht te worden om enerzijds in de communicatie met de

dienstleverancier te kunnen voorzien en anderzijds het door de dienstleverancier toegezegde

normniveau te controleren. Zeker als een organisatie meer delen van het ICT-proces aan

verschillende dienstleveranciers heeft uitbesteed, is een vorm van SLA noodzakelijk.

6.1 Plichten van de dienstverlener

Hier worden de eisen beschreven, zoals overeengekomen met de gemeente, waaraan de

dienstverlener dient te voldoen. Optioneel, kan dit ook in de inkoopvoorwaarden, het

contract/overeenkomst of de bewerkersovereenkomst worden beschreven.

Voorbeelduitwerking

Voorbeeld afspraken waar de dienstverlener zich aan dient te houden zijn:

Onmiddellijk melden van overschrijding van dienstenniveaus van kritieke processen

Onmiddellijk melden van beveiligingsinbreuken

Testen van wijzigingen en opleveren van testrapportages

Installeren van patches

Het bewaren en ter beschikking stellen van loggegevens

Het uitvoeren van een audit van de dienstverlening28

Relatie met de tactische Baseline:

Er is in contracten met externe partijen vastgelegd welke beveiligingsmaatregelen vereist zijn,

dat deze door de externe partij zijn getroffen en worden nageleefd en dat

beveiligingsincidenten onmiddellijk worden gerapporteerd (zie ook 6.2.3.3). Ook wordt

beschreven hoe die beveiligingsmaatregelen door de uitbestedende partij te controleren zijn

(bijv. audits en penetratietests) en hoe het toezicht is geregeld (6.2.1.6).

Controle (10.10)

Beheer van technische kwetsbaarheden (12.6)

Beheer van Informatiebeveiligingsincidenten (13)

28 Het geven van aanvullende zekerheid aan de gemeente over de mate waarin de bedrijfsvoering wordt beheerst en over de toereikendheid van de risicobeheersingssystemen, inclusief de daarbij behorende rapportages, alsmede de daarbij behorende advisering.

Page 55: voorbeeld service level agreement (sla) met aandacht voor ...

55

6.1.1. Borging van de beheersprocessen

Om als dienstleverancier de kwaliteit van de operationele exploitatieprocessen te kunnen

waarborgen en daarmee tevens de garantie te kunnen bieden dat de beveiligingsmaatregelen ook

daadwerkelijk functioneren, is het noodzakelijk dat de dienstleverancier een adequate

beheersorganisatie heeft ingericht De werkzaamheden binnen de beheersorganisatie zijn voor het

grootste deel gericht op het intern sturen van de verwerkingsprocessen.

De werkzaamheden met betrekking tot de help-/servicedesk en het service management zijn met

name gericht op de externe communicatie met de gemeente. Hierover dienen in de SLA dan ook

afspraken gemaakt te worden. Een belangrijke taak van de help-/servicedesk is het ondersteunen

van de gebruikers en het registreren van incidenten. Het service management verzorgt alle verdere

contacten tussen de gemeente en dienstleverancier. Het service management controleert of de

afgesproken dienstenniveaus ook daadwerkelijk gehaald worden, het zogenaamde service level

management.

Voorbeelduitwerking

Voorbeeld afspraken met betrekking tot de borging van de beheerprocessen zijn:

Algemene structuur en kwaliteit van de beheersorganisatie

Periodieke audit van het functioneren van de beheersorganisatie

Beschikbaarheid van de help-/servicedesk

Reikwijdte en deskundigheid van de help-/servicedesk

Incidentmanagement en response (en escalatie):

o afhandeling incidenten

o afhandeling calamiteiten

Wijzigingsbeheer

Rapportage van werkzaamheden van de help-/servicedesk

Procedures voor service management

Rapportage van werkzaamheden service management

Controle van toegezegde dienstenniveaus

Rapportage over kwaliteit van de dienstverlening

6.1.2. Logische toegangsbeveiliging

Om na de uitbesteding het bestaande beveiligingsniveau te kunnen handhaven, is het noodzakelijk

dat ook bij de dienstleverancier een adequaat systeem van logische toegangsbeveiliging is

geïmplementeerd. Een dergelijk systeem dient niet alleen bescherming te bieden aan de technische

systemen bij de dienstleverancier, maar ook aan de applicatie van de gemeente die bij de

dienstleverancier functioneert. Het autorisatiebeheer bewaakt de initiële instellingen, actualiseert

de autorisaties voortdurend en signaleert mogelijke inbreuken direct. Het autorisatiebeheer valt

weliswaar onder de verantwoordelijkheid van de dienstleverancier, maar de gemeente heeft hierop

een aanzienlijke invloed.

Voorbeelduitwerking

Voorbeeld afspraken met betrekking tot logische toegangsbeveiliging zijn:

Algemene kwaliteit van de logische beveiliging

Periodieke audit van de kwaliteit van de logische beveiliging

Classificatie

Page 56: voorbeeld service level agreement (sla) met aandacht voor ...

56

Beheren van gebruikers-id’s en wachtwoorden

Controleren en actualiseren van autorisaties

Rapporteren van inbreuken

6.2 Plichten van de gemeente

Hier worden de eisen beschreven, zoals overeengekomen met de dienstleverancier, waaraan de

gemeente dient te voldoen.

Voorbeelduitwerking

Voorbeeld afspraken waar de gemeente zich aan dient te houden zijn:

Doorgeven wijzigingen die van invloed zijn op de dienst

Het uitvoeren van functioneel beheer

Relatie met de tactische Baseline:

Aanvaardbaar gebruik van bedrijfsmiddelen (7.1.3)

6.3 Verantwoordelijkheden gebruikers

Hier worden de verantwoordelijkheden voor de gebruikers van de dienst beschreven.

Voorbeelduitwerking

Voorbeeld afspraken waar gebruikers zich aan dienen te houden met betrekking tot handelingen

die de beveiliging (negatief) kunnen beïnvloeden.

Relatie met de tactische Baseline:

Beveiliging beoordelen in de omgang met klanten (6.2.2)

Verantwoordelijkheden van gebruikers (11.3)

Toegangsbeheersing voor netwerken (11.4)

6.4 Monitoring van beveiligingseisen

Hier worden de beveiligingseisen beschreven die gemonitord dienen te worden in relatie tot de

dienst. De basis hiervoor is het contract/overeenkomst, de bewerkersovereenkomst en relevante

BIG-eisen. Optioneel, kan dit ook in de inkoopvoorwaarden, het contract/overeenkomst of de

bewerkersovereenkomst worden beschreven.

Voorbeelduitwerking

Voorbeeld beveiligingseisen die gemonitord dienen te worden zijn: Back-up en restore, incidenten,

patching.

Relatie met de tactische Baseline:

Beveiliging behandelen in overeenkomsten met een derde partij (6.2.3)

Bescherming van bedrijfsdocumenten (15.1.3)

Bescherming van gegevens en geheimhouding van persoonsgegevens (15.1.4)

Controle op technische naleving (15.2.2)

Page 57: voorbeeld service level agreement (sla) met aandacht voor ...

57

6.5 Addendum informatiebeveiligingsdienst voor gemeenten

Bij voorkeur heeft de dienstverlener met de IBD afspraken gemaakt over de verantwoordelijkheden

met betrekking tot informatieveiligheid in het Addendum Informatiebeveiligingsdienst voor

gemeenten (IBD) behorend bij het KING convenant.29 Hier wordt aangegeven of de dienstverlener

dit IBD-addendum heeft ondertekent of niet, middels een ja of nee.

6.6 Beperkingen, afhankelijkheden en overmacht

Vastlegging van beperkingen met betrekking tot het gebruik van de te leveren diensten, de

afhankelijkheid van derde organisaties en het beschrijven van situaties waarin de organisaties zich

kunnen beroepen op overmacht.

Voorbeelduitwerking

Voorbeeld beperkingen met betrekking tot het gebruik van de te leveren diensten zijn:

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. Bijvoorbeeld telecomprovider ten

behoeve van communicatie

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)

6.7 Aansprakelijkheden

Vermelding van zowel de aansprakelijkheid voor de bij de gemeente opgestelde apparatuur en/of

programmatuur als van de aansprakelijkheid van de dienstleverancier voor het functioneren van de

gemeentelijke dienstverlening in relatie tot de afgenomen dienstverlening. Bijvoorbeeld in geval

van storingen of calamiteiten.

29 https://www.ibdgemeenten.nl/downloads/?id=2073

Page 58: voorbeeld service level agreement (sla) met aandacht voor ...

58

7 Kosten

7.1 Kosten dienstverlening

Hier worden de financiële consequenties (vergoedingen) met betrekking tot de dienstverlening

beschreven. Bijvoorbeeld per gebruiker, per systeem, gerelateerd aan beschikbaarheidseisen van

de dienst. Benoem hierbij de diensten/producten die binnen de (standaard) dienstverlening vallen

en welke diensten/producten meer kosten.

7.1.1. Prijzen

De hoogte van de vergoeding die betaald dient te worden, dient te worden vastgelegd, inclusief

grenzen aan stijgingen. Hierdoor krijgt de gemeente zekerheid met betrekking tot de jaarlijkse

kosten.

Voorbeelduitwerking

Voorbeeld vast te leggen items zijn:

Alle genoemde prijzen zijn in Euro's, inclusief of exclusief BTW, verblijfs- en reiskosten

Tarieven: dienstleverancier is gerechtigd jaarlijks per kalenderjaar de geldende tarieven voor

haar dienstverlening te indexeren. Bijvoorbeeld: prijsstijgingen zijn gemaximaliseerd tot

<percentage> % per <periode> of maximale prijsstijgingen conform het

consumentenprijsindexcijfer van het Centraal Bureau voor de Statistie (CBS). Dit gebeurt door

middel van een schriftelijke kennisgeving aan gemeente (afnemer/klant/opdrachtgever) op

een termijn van tenminste drie maanden voor het verstrijken van het kalenderjaar

Voor tarieven buiten de normale service tijden gelden de volgende opslagpercentages:

o Werkdagen (Tussen 07:30 uur en 18:00 uur: 0%; Voor 07:30 uur of na 18:00 uur: 50%)

o Zater-, zon- en feestdagen (Tussen 07:30 uur en 18:00 uur: 100%; Voor 07:30 uur of na

18:00 uur: 100%)

7.1.2. Betalingsvoorwaarden

Afspraken aangaande betaling van overeengekomen vergoedingen dienen te worden vastgelegd

om onduidelijkheden en/of problemen hieromtrent te voorkomen.

Voorbeelduitwerking

Voorbeeld vast te leggen items zijn:

Betalingscondities:

o Diensten: facturering geschiedt maandelijks, achteraf

o Betalingstermijn: <aantal> dagen na factuurdatum

o Op welk bank-/girorekeningnummer betaald dient te worden

o Welke regels gelden bij te late betaling door de gemeente

o Wat te doen indien de gemeente niet akkoord gaat met de factuur

Leveringsvoorwaarden

Page 59: voorbeeld service level agreement (sla) met aandacht voor ...

59

7.2 Sancties, bonussen

Hier worden de regels voor sancties, bonussen met betrekking tot de dienstverlening beschreven.

Voorbeelduitwerking

Denk hierbij aan:

Bonus-malusregeling:

o beter presteren dan afgesproken

o gevolgen van het niet (volledig) nakomen van afspraken (bijvoorbeeld prestatie eisen)

Hoe de schade als gevolg van een onvoldoende functionerende dienst kan worden verhaald

Beschrijving van overleg in geval van problemen (eventueel het verwijzen naar de clausule

over geschillen)

Boeteclausules of andere financiële strafbepalingen

Page 60: voorbeeld service level agreement (sla) met aandacht voor ...

60

8 Verklarende voordenlijst

Optioneel: In de verklarende woordenlijst wordt een uitleg gegeven van de belangrijkste begrippen

die van toepassing zijn binnen de context van alle documenten behorende tot deze SLA.

8.1 Definities

Term Definitie

Afhandeltijd De tijdsperiode tussen aanmelding van een incident

of verzoek en het moment waarop het incident of

verzoek is afgehandeld. De tijd die derde partijen

nodig hebben en waar Opdrachtnemer op moet

wachten ter afhandeling van het incident, telt niet

mee in de berekening van deze tijdsperiode.

Applicatie De standaard en maatwerk software, uitgezonderd

besturingssoftware behorende tot de Applicatie

[naam invullen].

Applicatiebeheer Het beheer van de applicaties zoals beschreven als

Servicegroep ‘Applicatiebeheer’ (AB)

Applicatie Services De verzameling activiteiten behorend tot de Service-

groepen:

Applicatie Service Management (ASM)

Applicatie Onderhoud (AO)

Applicatie Beheer (AB)

Applicatie Ontwikkeling (AO)

Beschikbaarheidsniveau Per te leveren dienst wordt een

beschikbaarheidspercentage afgesproken.

Bijvoorbeeld 99,5% of 99,9%, afhankelijk van de

producten die de gemeente kiest.

Besturingssoftware Standaard software dat bedoeld is voor de besturing

van een systeem en wat minimaal nodig is om de

hardware en applicaties correct te laten functioneren.

Bewerkersovereenkomst De bewerkersovereenkomst bevat afspraken en

maatregelen die de verantwoordelijke genomen wil

hebben door de bewerker.

Deliverable Engelse term voor ‘op te leveren product’, waarbij het

op te leveren product zodanig concreet en meetbaar

dient te zijn, dat door de Opdrachtgever vastgesteld

kan worden of het aan de gestelde eisen voldoet.

Dienstencatalogus De dienstencatalogus bevat een gedetailleerd

overzicht van de aangeboden diensten en het niveau

van de dienstverlening. De dienstencatalogus is

bedoeld voor de klant en moet de diensten in voor de

klant begrijpelijke bewoordingen beschrijven.

Dossier Afspraken en Procedures (DAP) Dit document beschrijft in detail de dienstverlening,

werkafspraken en procedures ter uitvoering van de te

leveren diensten.

Page 61: voorbeeld service level agreement (sla) met aandacht voor ...

61

Dossier Financiële Afspraken (DFA) Dit document beschrijft de financiële afspraken die

deel uitmaken van deze Overeenkomst.

Hersteltijd Is gelijk aan Afhandeltijd, maar dan meer specifiek

met betrekking tot systeemproblemen.

Implementatievoorstel Een document dat eenduidig specificeert wat er

geïmplementeerd wordt en hoe dat gedaan wordt.

Concreet betekent dit dat een dergelijk document de

aanpak, organisatie, planning en kosten specificeert.

Incident Een vraag, klacht of probleem van een gebruiker of

andere relatie met betrekking tot een bepaalde dienst

of systeem.

ICT-Infrastructuur Het geheel van hardware en standaard software waar

de te beheren applicaties op locatie van en onder

verantwoordelijkheid van Opdrachtgever op draaien.

Ketenbeheer Technisch en Applicatiebeheer van een keten van

functioneel en technisch samenhangende systemen

en netwerken.

Maatwerk Specifiek ten behoeve van Opdrachtgever te

ontwikkelen of ontwikkelde programmatuur dan wel

aanpassingen in de standaardapplicatie specifiek ten

behoeve van Opdrachtgever.

Melder Een door Opdrachtgever persoon die een Incident

mag aanmelden bij de helpdesk van Opdrachtnemer.

Nationale Feestdagen Nieuwjaarsdag, Goede Vrijdag, Pasen, Koningsdag,

Hemelvaartsdag, Bevrijdingsdag, Pinksteren,

Kerstmis.

Onderhoudswindow Een (afgesproken) tijdvak waarin onderhoud

plaatsvindt die mogelijk verstoring veroorzaakt in het

gebruik van de dienst.

Operationeel beheer Applicatie Systeem Omvat in dit verband alle activiteiten die waarborgen

dat het Applicatie Systeem operationeel beschikbaar

is conform het overeengekomen

beschikbaarheidsniveau.

Optionele dienstverlening Dit zijn de werkzaamheden die in het kader van deze

Overeenkomst uitgevoerd worden, en waarvan de

kosten ten laste gebracht worden van de Support

reserve.

Overeenkomst De overeenkomst inclusief bijlagen en eventuele

Appendices tussen Opdrachtgever en Opdrachtnemer

betreffende de voorwaarden die gelden voor het

uitvoeren van de Dienstverlening inzake het ter

beschikking stellen van de Applicatie.

Probleem Een door een gebruiker of andere relatie

gepercipieerde afwijking van wat als normaal gedrag

van een dienst, keten of systeem beschouwd wordt.

Een door de beheerder vastgestelde fout in het onder

beheer zijnde systeem (applicatie) of

netwerkverbinding.

Page 62: voorbeeld service level agreement (sla) met aandacht voor ...

62

Programma van Eisen Een document waarin de functionele eisen met

betrekking tot een te ontwikkelen of uit te breiden

systeem of keten van systemen zijn gespecificeerd en

dat door of namens de Opdrachtgever geaccordeerd

dient te worden.

Release Een nieuwe versie van de applicatie, waarin in

vergelijking met voorgaande versies nieuwe

functionaliteiten zijn opgenomen.

Responstijd De tijdsperiode tussen de aanmelding van een

incident of verzoek en het moment waarop een eerste

terugkoppeling wordt gegeven aan de aanmelder.

Service afhandeling Service afhandeling omvat de afhandeling van

aangemelde incidenten en ingediende verzoeken. Een

incident wordt in dit verband gedefinieerd als een

probleem, storing, klacht of vraag met betrekking tot

het gepercipieerde functioneren van het systeem.

Servicewindow of Servicetijd Dit wordt gedefinieerd als het tijdraam/-vak,

waarbinnen de gedefinieerde dienstverlening met een

zekere garantie en met een afgesproken

beschikbaarheidsniveau wordt aangeboden.

Service Improvement Plan (SIP). Het SIP bevat acties, doelen en opleverdata die de

verbetering van een ICT-dienst tot doel hebben.

Service Level Agreement (SLA) Overeenkomst met betrekking tot de te leveren

beheerservices.

Service Quality Plan (SQP). Het SQP bevat de noodzakelijke informatie die nodig

is om de kwaliteit van een ICT-dienst bij te sturen. In

het SQP worden voor elke dienst streefwaarden

gedefinieerd, in de vorm van Perfomance Indicatoren

(PI’s), zoals responstijden, beschikbaarheid,

doorlooptijden, kosten et cetera.

Standaard software Software dat standaard ('off the shelf') beschikbaar is

en over het algemeen een bepaalde standaard

functionaliteit levert.

Systeem Het geheel van hardware en software dat een

samenhangende verzameling van functies

representeert.

Systeemsoftware Alle software van een systeem, dat wil zeggen

besturingssoftware (bijvoorbeeld Windows NT of

Windows server 2003), standaard softwarepakketten

(bijvoorbeeld Oracle, MQseries) en maatwerksoftware

(bijvoorbeeld kernapplicaties).

Technisch Beheer Applicatie Wordt in dit verband gedefinieerd als een

serviceverlenend proces dat zich onder

verantwoordelijkheid van Opdrachtgever richt op het

operationele beheer in het algemeen en het

onderhoud en beheer van de ICT-Infrastructuur van

het Applicatie Systeem in het bijzonder.

Vaste kosten De overeengekomen en in het DFA vastgelegde

Page 63: voorbeeld service level agreement (sla) met aandacht voor ...

63

periodieke kosten voor de gespecificeerde diensten.

Versie Een nieuwe Versie, een upgrade waarmee eventuele

geconstateerde fouten in het computerprogramma

worden verholpen.

Verzoek Een vraag om een bepaalde activiteit uit te voeren

die leidt tot een duidelijke deliverable.

Werkdagen Alle dagen met uitzondering van weekenddagen en

Nationale Feestdagen.

8.2 Afkortingen

Afkorting Definitie

AB Applicatiebeheer

AS Applicatie Service(s)

ASM Applicatie Service Management

AO Applicatie Onderhoud of Applicatie Ontwikkeling

DAP Dossier Afspraken en Procedures

DFA Dossier Financiële Afspraken

PvE Programma van Eisen

SIP Service Improvement Plan

SLA Service Level Agreement

SQP Service Quality Plan

TB Technisch Beheer.

Page 64: voorbeeld service level agreement (sla) met aandacht voor ...

64

9 Bijlagen

Denk aan andere SLA's, rapportageformat, contracten, beveiligingseisen et cetera.

1. Rapportage templates

a. Contractmanagement (SLA wijzigingen)

b. Opdrachtmanagement (dienstenniveaus op maand basis)

c. Service-/helpdesk: openstaande en afgehandelde incidenten, status openstaande

incidenten, overschrijdingen.

d. Template voor wijzigingsverzoeken

2. Document Afspraken en procedures (DAP)

3. Onderhoudsdocumentatie

4. Beveiligingseisen uit de BIG

5. Woordenlijst/begrippenlijst

Page 65: voorbeeld service level agreement (sla) met aandacht voor ...

65

Bijlage 1: Literatuur/bronnen

Voor deze publicatie is gebruik gemaakt van onderstaande bronnen:

Titel: diverse artikelen (waaronder Inrichtingsmodel IT-beheer en Checklist Service

Level Agreement SLA)

Wie: Wiebe Zijlstra

Uitgeverij: ZBC kennisbank

Link: http://zbc.nu

Titel: Beveiliging en Service Level Agreements

Wie: diverse auteurs (Platform voor Informatiebeveiliging (PvIB))

Uitgeverij: Ten Hagen en Stam

Datum: 2001

ISBN-10: 90-440-0223-6 (niet meer leverbaar)

Link: http://www.pvib.nl/?page=6398483

Titel: Cloud SLA de best practices van Cloud Service Level Agreements

Wie: Bart de Best & Pascal Huijbers

Uitgeverij: Leonon Media

Datum: 2014

ISBN-10: 90-71501-73-9

ISBN-13: 978-90-71501-73-9

In juni 2014 heeft de Cloud Select Industry Group - subgroep Service Level Agreement (C-SIG-

SLA) van de Europese Commissie een SLA richtlijn gepubliceerd.30 Deze SLA richtlijn voor Cloud

diensten dient ook als input voor de Cloud SLA standaarden die door de Internationale Organisatie

voor Standaardisatie (ISO) op dit moment worden ontwikkeld. Het gaat hierbij om een drietal

standaarden, namelijk:

ISO/IEC 19086-1 - Information technology -- Cloud Computing -- Service Level Agreement

(SLA) Framework and Technology -- Part 1: Overview and concepts

ISO/IEC 19086-2 - Information technology -- Cloud Computing -- Service Level Agreement

(SLA) Framework and Technology -- Part 2: Metrics

ISO/IEC 19086-3 - Information technology -- Cloud Computing -- Service Level Agreement

(SLA) Framework and Technology -- Part 3: Core requirements

30 https://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-standardisation-guidelines

Page 66: voorbeeld service level agreement (sla) met aandacht voor ...

66

INFORMATIEBEVEILIGINGSDIENST V00R GEMEENTEN (IBD)

NASSAULAAN 12 2514 JS DEN HAAG

POSTBUS 30435 2500 GK DEN HAAG HELPDESK 070 373 80 11 ALGEMEEN 070 373 80 08 FAX 070 363 56 82

[email protected] WWW.IBDGEMEENTEN.NL