Upload
vuhanh
View
319
Download
3
Embed Size (px)
Citation preview
VOORBEELD SERVICE LEVEL AGREEMENT (SLA) MET AANDACHT VOOR INFORMATIEBEVEILIGING Een van de producten van de operationele variant van de Baseline
Informatiebeveiliging Nederlandse Gemeenten (BIG)
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
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.
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
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
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
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
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
9
iii. Leeswijzer
Hier wordt beschreven hoe dit SLA het beste gelezen kan worden, afhankelijk van de functie/taak
en achtergrondkennis van de lezer.
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.
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.
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).
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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
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.
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.
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
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.
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
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
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
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
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)
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
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
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
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)
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
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.
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
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.
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.
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:
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).
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.
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
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)
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
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
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
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.
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.
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
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.
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
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
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